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PREFACE 


This document presents results of work supported by the Uw hnforcement 
Assistance Administration, U. S. Department of Justice, under tlie Omnibus ('rime 
Control and Safe Streets Act of lb6S, as amended. It was sponsored under an inter- 
agency agreement with the National Aeronautics and Space Administration througli 
Contract NAS 7-100. Points of view or opinions stated in this document are those of 
the authors and do nut necessarily represent the official position of the U. S. Department 
of Justice. 
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This liook hits lit'tin picpaie i iiiu! tllMiiliulcd in pntvidi' piiWic siilViy plimniiin 
poi'snimel Willi u coinpuci source ol' iiirormation on one of llie most Impoilani aspecis 
of police connnmul ami control iiulomalion. namely compiilcr-aUleil dispalcli (CAD) 
systems, A CAD system Is valiialile in itselClor llie improvements it proviitesin llie critical 
dispatclilng fimction.aml can lie the miclcus for a completely anioniiiieil police coiiimand 
and control operation. 

This volume is one of a series prepared under the sponsorsliip of the Law luilbrce- 
ment Assistance Administration (l.LAA) to provide planning guidelines on the various 
aspects ol‘ police eommand and control automation, llie complete scries consists of the 
following documents: 

Title 

Application of Mobile Digital Communications 
in i.aw Unforcement 

Application of Computer' Aided Dispatch 
in Law enforcement 

Application of Auloiiiatic Vehicle Location 
in Law 1-nfurccment 

Patrol Porce Allocation in Law Enforcement 

Advanced Command and Control Systems 
in l aw Enforcement 

The scries was prepared by the Jet Propulsion Laboratory of the California Institute 
of Technology, using the results of studies sponsored by LEAA at JPL as well as at other 
institutions. The documents are being distributed as part of LEAA’s mission of giving 
technical assistance to state and local law enforcement agencies. They are addressed to 
the local law enforcement planner who must face practical working problems in decid- 
ing whai degree and kind of automation best suits his department. Our intention has been 
to give him the basic understanding he needs to make such a decision, and procedures lor 
making the associated analyses or having tliem made. The manuals are developed within 
the framework of the overall command and control system so that potential I'cnefils 
of individual innovations can be evaluated in terms of improved system performance. 

The technologies that arc available to law enforcement agencies today have the 
promise of making their operations more efficient as well as more effective. Our liope 
is that tills series of docuiiieiits will provide a clear and concise picture oi wliat that 
promise is and what is involved in making it a reality. 
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ABSTRACT 

A set of planning guidelines for the applieutlon of computer-aided dispatching 
{(;a 13) to law enforcement is presented. Some cascntiai characteristics and applications 
of CAD are outlined; the results of a survey of systems in the operational or planning 
phases are summarized. Requirements analysis, system concept design, implememutlon 
planning, and performance and cost modeling are described and demonstrated with 
numerous examples. Detailed descriptions of typical law enforcement CAD systems, 
and a list of vendor sources, arc given in appendixes. 

This document is one of a series of five guideline manuals on mobile digital com- 
munications, CAD, automatic vehicle location, patrol force allocation, and multiagency 
command and control systems for law enforcement applications. 
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1. INTRODUCTION 


Increasing llie degree of automation of police command 
and control operations has been a topic of growing interest 
over the past five years. The Law Lnforcement Assistance 
Administration Itas a strong interest in tiie field and lias 
supported several departments in their Implementation ot 
computer-aided dispatch (CAD) systems. Such systems are the 
basic step In the automation of police command and control; 
a few law enforcement agencies have implemented ('AD sys- 
tems, more are planning to do so, and nearly all arc interested 
in following developments in the field. 

There are two major reasons for the growing interest in 
CAD. The first is that departments want to Improve the man- 
agement of their resources in one or more of the following 
ways: 

• Decrease response time to citizen calls for service. 

• Increase productivity by enabling a patrol unit to 
respond to more calls per shift, or 

• Match patrol assignments better to hours and loca- 
tions of expected need. 

• Reduce dispatching errors. 

• Reduce hand preparation of reports. 


• Have instant access to activity statistics, atid use 
such statistics in foiiuulating budgets and deploy- 
ment strategies. 

'Hie second reason is that CAD provides a framework 
for bringing together 'he many new tools lor command, con- 
trol, and communications that are computerized or computer- 
compatible. In addition to computers themselves, these 
include: 

• Mobile and portable digital terminals. 

• Dynamic channel assignment. 

• Automatic vehicle location systems. 

• Keiuoie data base iin|Utry. 

• Management reporting systems. 

• dll emergency telephone number service. 

• Regional cooperative dispatch among adjacent 
jurisdictions. 

The interest in CAD systems reflects their potential for 
improving operations in the ways mentioned, but tliere are also 
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poieiitiitl drttwbackN thui dumld be rei.'n^nl/.o(] when plann are 
being made. One obvlouN drawback ia that deparlmonta will 
grow more dependent on technology and on apoclallstN attch 
an coinpoter aynteni engineer, pmgraininern, and data procenx* 
ing inanagetH; this Umita the autonomy and in aome waya the 
flexibility of tiie department. The coal of Inatalling a CAl) aya> 
tern and converting operationa to It la atlll higl), eapcclalty for 
aoftwarc, and will remain an until enougit ayatema have been 
Inatalled to permit aome degree of atandardl/.atlon. The aophla< 
ticated hardware will need apeciali/.ed maintenance over ita 
lifetime, and the coat may be a burden, t'inally, all automated 
ayatema cun bo expected to have failures and there must be u 
backup mode of operation fur such times, The backup mode 
must be kept exerciaed and ready fur use at any time, 


The purpose of this ducumont is to provide aome back* 
ground and guidelines that will assist law eitforccment agencies 


in solecting and evaluating CAD ayatema and in developing 
operational plana for their use. The next chapter is a brief 
review of the current status of Implementation of (‘AD sys> 
tents around the country: since the situation Is changing very 
rapidly, the survey does not include all agencies that are plan* 
ning for or are in the process of implementing ('AD systems. 
(Iiapter 3 represents a summary description of what a CAD 
system Is and how It operates, as background for the rest of 
tire document. Cliuptcr 4 outlines the process of planning for a 
CAD system, followed by plumtlng guidelines in ('hapters .5, 6, 
and 7. CItupter 5 covers the analysis of requirements, while 
('huptcr (\ describes the hardware and software components of 
a CAD system and gives an example of how u proposed system 
cun be siacd. It also discusses some principal trade-offs that arc 
available to tire CAD system planner. Chapter 7 gives some 
guidelines fur preparing an impicmeiuutiun plan, and finally 
Chapter b discusses brlctly the cost versus benefit analysis of a 
CAD system. 
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2. STATUS OF COMPUTER-AIDED DISPATCH 




III (lie course nl' prepnrliig muteriul fur lliiK iiiuiiuul, we 
euiiUietcd tivvorul liiw eiiroreeineiit ii^eneien tliut liuve itiMulled 
CM) syMtcniR iiiul dltieiiKiied their experiences in deiiidiiinK uiul 
iinpleineiitiii^ the syfUems us well us the impact uii their opera- 
tiotiR. Actual experience with (!A1> Is Ktill very limited, since 
with one exception (ho systems became operational In l*)73 
ami arc still in the shakedown stage. Some of the major charac- 
teristics of these existing systems arc summarlir.ed in Table I . 

An important observation about CAD systems is that the 
trend to their use is Just beginning; as of mid-l‘)7.^, only about 
10 percent of the 13.S police departments in jurisdictions of 
mure than 100,000 population hud a CAD program, and as 
noted above these were still new. As the table shows, there is a 
range of capabilities in the existing systems, since they neces- 
sarily rcilect different requirements in the form of rate of 
culls for service, size of patrol force deployed at a given time, 
and extent of other automated files that cun interface with 
CAD. The basic functions performed by the CAD systems arc 
quite similar and, us the state of the art matures, an increasing 
degree of standardization should be anticipated. 

The feasibility of computer-aided terminals for com- 
plaint taking and dispatching is well established. Most of the 
recent installations have gone into operation without major 
start-up problems or subsequent modifications, although 
computer-aided dispatch systems have by no means reached 
any degree of standardization. Several design trends can be 
Identified, however. All but the relatively small agencies 
employ two-stage configurations, one station for complaint 
taking, and a second station for dispatching; Glendale and 
Palm Beach County receive calls and dispatch from the same 
stations, San Diego and New York City further subdivide the 
complaint-taking function into primary and secondary sta- 
tions, with longer calls and report-taking handed off to the 
latter operators. 

Most agencies have dedicated computer processing units, 
all of which arc of the minicomputer class, althougli report 
generation is usually performed by the municipal data process- 


ing agency. The two shared computer installations have not 
experienced difficulties with this urruiigeincnt, although pri- 
ority Is given to the (’Al) operation In tuder to deliver near 
real-tlnte support, 

The urea of greatest concern is that of display sl/e and 
format; many agencies have spent several months designing 
and testing displays and sU|tportlng software prior to Inslullu- 
tlon, or have experienced costly redesigns if developineni test- 
ing was omitted. Une "lesson learned" to date Is lire value of 
testing work station designs in near-operational environments 
prior to hardware development; it Is nearly impossible to 
establish good dls|)luy formats from drawings alone, or from 
static mock-ups. 

Burly dispatch display formats were designed for slitgle 
CRl screens, usually with the top portion of the screen used 
for incidcut-rclutcd information and the lower liulf for field 
unit status. Tills approach was (and is) adequate for relatively 
small agencies, but has proved unworkable for large, heavily 
loaded agencies, wbicli liuve resorted to dual screen arrange- 
ments, one for incident data and the second for field unit 
status. This allows more Information to be shown at one time, 
reduces the "busy” activity of a single screen, and reduces 
the number of manipulations required of tlio dispatclier. 

Also noted in Table 1 Is the luck of experience with 
address verification and prior history files. Geofiles developed 
by municipalities for other purposes, such as lax or utilities 
functions, oftentimes are too cumbersome for dispatch pur- 
poses and must be reworked for these applications. Updating 
these flies can be an expensive proposition. No agency has a 
prior history file in operation at the present time. 

In view of the early stage of development of CAD sys- 
tems, it will be extremely Important over tlic next few years 
for any planner considering the implementation of a new 
system or the upgrading of an existing one to observe at first 
hand as many other systems as he can. and to learn us much as 
possible from the experience of otiicrs. 
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3. DESCRIPTION OF COMPUTER-AIDED DISPATCH SYSTEMS 


Ik im wIihi Hk iwiiitf 

u liyMom (hut iicfiuUk iIk* iiitrmul (iporutUiiiii ot iiumllliitF sf*iv< 
luc chIU I'rom W\e pulFilw to be iinslMed by miikliiK use ol' the 
Npocliil eupubllitiCK ol’ the eomputei. Thene ciipitbllliles ure. 
I'ot tills itpplieuiloii. those ol' perfouiilng simple, lepeiiilvc. 
routine lusks tirelessly mul without error, storluK luul retriev- 
ing Information almost Instantly, uiul ereailng CK'l' displays 
from storcil data and keyboard Inputs. The eompuiei docs not 
replace the unkpiely Imnum capabilities retpilred for law en- 
forcement command and control, and can only assist the 
human operator. 

The dispatching operation consists of a How of com- 
plaints or incidents, originating with public calls to the com- 
plant board and moving on to tlie dlspamhcr (who assigns 
patrol units and coordinates any rciiuired support), to the 
patrol units (who iiivcstigate the incidents), and buck to the 
dispatcher with information on status changes of patrol units 
and information on closed incidents. (Unusual siiuulions such 
us disasters or civil disorders naturally full outside this simple 
ftamework.) This dispatching operation is under the control of 
one or more supervisors (depending on the size of the depart- 
ment), and must be planned and managed along with all the 
other functions and resomces of the department. A CAD sys- 
tem supports all these elements of the department, in the ways 
listed in Table 2. 

As shown in Figure 1 , a typical computer-aided dispatch 
system Is comprised of a central processor, a data base system, 
and keyboard-display terminals for complaint board operators, 
dispatcher, and support personnel. The data base system con- 
tains several files, including; 

• Incident records, a log for each incident from 
initial call to log off or final disposition. 

• Status of fielJ units, a summary of tlie status, 
assignments, and uvuilablllty of velilcles. 

• (ko- or atblrcss file, a listing of all addresses (to 
the block level) within (be Juiisdictlon, Including 
the corresponding beat k.umber and reporting area, 

• l*ersonnet, a log of personnel status and assignments. 

• Dangerous situation, a file of addresse* of danger- 
ous persons or places. 

• Vehicle and crinr .nformation, local files of stolen 
vehicles and wants and warrants. There may also 
be access to remote files such us DMV.NCIC, etc. 


Ihc How of liilotmalioii Ihfough the system Is as lollov : 
The complaint board opeiaiui euiers Inlormatltm ic<,/i'--d 
from a cltl/eii uireclly iiito the daiii Hies through ihe key > . ol 
lermimil mul central processor, No Imml-wrilicn or K-.y- 
punchetl data are retiulredi all Inlomiaiion about the com- 
plaint (Inbumant's name, address, leleplume miinher. and 
nature of complalul) Is typed directly Into the file, through 
the termimd. Once llie Infomtaiion has heon entered Into the 
system, the Incident Is passed to the dispatch terminal (culls 
not ret|idrliig a dlsi>alcli cun he referred to the proper buieau 
or agency). Wlicn tlie Incidom Is first entered into tlie com- 
puter Hies several pr.rccsscs begin t>, operate concurrently; 
Hie computer assigns a case numL* .md time 'Jgs the Incident, 
verilies that the adi'.ress does in ‘act ex!-.v ,n I i', witliin tlie 
agency's jurlsdictioi , deie.mtnes .he b.e^o ji. u.ber and avail- 
ahlc mills as.signed '.o ib.i beat, and " . . is any history at 
lliai location (e.g,. ' v K.cidenf a •gF'e.ed gim t!c.). A 
niic-llne siuiimji;- m \1 m nicidenl is then ..Hiuglii ui' - n the 
dispaii;*- ’ s- I'spiay s.rccn, A key element in die prtu >ss is 
the uss.giimcwl of a prloiity level to the li.ciJent; nonnal'c. 
the priority is assigned h> the compiuiiit boj>d operator in 
accordance with agency pr.iccdures when the c.,il is rece: cd. 
Tlie dispalclier then calls up the complete Ineident record on 
the display screen so tl.at a field uni' an be assigned and 
necessary information rilayed to it by voice or digital com- 
inuiilcation links, The dispatcher types in the ID of the unit 
dispatched, and the computer updates tlie unit status and 
Ineident files and logs the time, Activity logs and statistical 
reports arc prepared for each sliift, cueli day, each wcek.eacli 
month, and as recpiired for iiiletnal nianagemetit as well as for 
reporting to state and federal agencies. 

The department chief and his watch commanders use 
one set of reports for the deployment of personnel and mobile 
units, bused on computer siniimaries of incidents by reporting 
district, type of crime, and time of day, as well as averages Ibr 
corresponding prior time periods by reporting district and type 
of crime. The computer also prepares summaries of aetivltles 
of the personnel and mohllc units to indicate how each officer 
and each unit have spent their time: on assignmctil. on |)uUol. 
In court, special assignment, on leave, etc, Some agencies pro- 
vide terminals througli wlilcli operations managers can access 
the data base and retrieve statistics for near real-time applica- 
tion of resources. 

One final comment about field reports. Patrol olficers 
report some iiiforniulioti before clearing for a new lusigmiieni, 
This information is entered by the dispatcher prior to log off. 
and is retained within the computer file unlil final disposition, 
wlilcii could occur many months after the incident took place. 
Ilic field officers may prepare disposition reports at sliilt 
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Oomminil and Control Fonotlon 


What lha Computar Don 


Complaint board 

Displays the format of tha complaint rtoord on tha oparator's console scraan. 

As operator antars tha complaint data on the kayboard, displays tha Input data In the appro- 
prleta spaoas on tha format (this tats tha operator check on what ha hat antarad). 

Automatically antars ceta number, data, tima, and beat numbar. 

Chackt Input deta for validity Idupllceta cates, Invalid addrasHS, ate,). 

Maintains backlog status of dispatchers and assigns complaint to dispatcher handling that beat. 

Dispatch contoli 

Displays all complaint records assigned to the position lor holOs In memory those that over- 
flow tha screen, allowing operator to page through the memory as desired). 

Displays status of all petrol units under dispatcher’s control, 

Maintains status records automatically as units era assigned, casas cleared, or status changes 
comet In from units. 

Autometically enters cate numbar, data, and tima case ettigned to patrol unit. 

ChKks date for validity. 

Accetset external filet to determine nearest cross street, history of incidents, etc. at the address. 
Accatset remote filet (warrants, DMV, NCIC, etc.) at required. 

Stores all records of cates cleared. 

Patrol units 

Updates status of petrol units. 

Accesses remote filet (DMV, NCIC, etc.) directly upon request of officer. If equipped with 
digital terminal, or operator. 

Generates cate reports for routine cates from officer Inputs. 

Supervisor 

Allows supervisor to call up on hit display any incidents In progress. 
Provides direct, Immediate access to complaint/lncldent filet. 
Generates activity reports for each shift. 

Maintains activity log. 

Mansgamant 

Maintains complete records of all activities. 

Generates statistical reports at needed, tortlng Incidents by type, aree, patrol unit, time of day, 
date, or other clestiflcatlon. 


L 


(crniinatiun lo comply with legal rc(|iiircment!i. These woulit 
constitute the only manually generated documents. One 
agency uses a tcclmkiuc In which the officer at shift terinina- 
tion telephones in the infonnatiou to a keyboard operator 
who enters the data into the computer files; the officer need 
not make a written report. 


It) summary, the kinds of improvement in the dispatch 
lug operation that cun be expected from implementation of a 
CAD system are: 

Accuracy . CAD eliminates many errors due to repeated 
handling of cards, slips, time stamps, etc. and copying of in- 
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Fig. 1. Computtr>tldid dlipitch tunctionil dligram 


formation from one form to another. It automatically edits 
human Inputs for such errors as invalid codes, improper case 
number assignments or patrol unit designations, and in more 
sophisticated systems can compare an input address with files 
of valid addresses. 

Operator Per/'ortnance. CAD relieves the operator of 
many tedious mechanical tusks, thus Improving operator per* 
formunce by allowing concentration on the essentials of 
decision-making and supporting field units. 

Speed, A CAD system cun carry out some tasks, such us 
file updating or file look-up, much faster than is possible in 
manual systems. The speed of the computer also makes 
possible some tusks (such us checking for previous incidents 
at the address) that would nut be possible in a manual system 
because of the time required. CAD cannot, however, reduce 
the time it takes an operator to listen to a verbal message or 
talk to a caller or patrol unit, or to decide what should be 


done next. Tims it sliould not be expected that a CAD system 
will necessarily increase the number of calls per hour that can 
be handled by a complaint board operator or dispatcher. 

Span of Control, Similarly, a CAD syslem does not 
necessarily enable a dispatcher to control more patrol units 
even though it does provide a more efficient way of keeping 
track of incidents, resources, and assignments. One dispatcher 
for 30 to 50 patrol units Is still a heavy load during hours of 
peak activity. 

Paperwork Reduction. Since all the Information about 
an incident is entered into the computer files In real time, It is 
available for generating reports that are needed. These include 
case reports, which for the most part can be produced, by the 
computer directly based upon information provided by the 
officer. This saves considerable time of officers and clerks, and 
even where a report must be prepared by an officer the com- 
puter can prepare the routine portions of it. The same Infor- 
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matlon on incldentii can he used In the preparation of aliift 
activity reports or management reports of various typos 
(special computer proftrams must be written to select and 
organi/.e the information from the data base for each type of 
report, 

lixpamUm of CapahlHws, A CAD system can serve us 
the nucleus for the addition of other capabilities making use of 
or building on tire automated command and control equip* 
mcnt and procedures. The computer, consoles, peripheral 
equipment, and software that are needed for a CAD system 
provide the basis for adding such other capabilities as: 

• Automatic vehicle location. 

• Automatic generation and receipt of digital 
messages. 

• Joint dispatching with tire and emergency medical 
services. 

• Joint dispatching of adjacent jurisdictions. 

Wliile all the above kinds of improvement are significant, 
the planner must keep in mind the inlierent drawbacks men- 
tioned in Chapter 1 as well as some additional cautions: 

ManIMachine Interaction. Tlie optimum way for a dis- 
patcher to interact with the computer has not yet been deter- 
mined. Even in the best CAD system the dispatcher must page 
through several formats to find the right one, and then enter 
the Information, while additional messages are arriving and 
events occurring in rapid succession. The workload imposed 


on a dispatcher is still stressful, and we arc not providing the 
kinds of formats, displays, and data entry devices that would 
reduce this stress appreciably. 

I’W Consmwtion, Witllo one of the major advantages of 
a CAD system is the capability of accessing any number or 
size of files in fractions of a second, there is still the problem 
of creating files in machine-readable form. The conversion of 
large amounts of data into machine-readable form requires 
human labor and is expensive; an example is the geographic 
data file that is used to verify addresses and identify tl\c 
nearest cross street. This file also requires labor to update, 
although it does not change rapidly and the task may not be 
very large. The esseittial files, such as those for maintaining 
veliicle status, are relatively easy to assemble. Several of the 
remote files that would be assessed by the CAD system, 
such as auto registration data and the NCIC, are already in 
machine-readable form and only the interface needs to be 
provided. 

System Effects. When a CAD system has been imple- 
mented, it becomes the core of tlic command and control 
system. For this reason, it is likely to affect many other 
operations and procedures. Those effects extending beyond 
the dispatching operation itself must be identified by the 
planner and taken into account in the planning; otherwise 
the CAD system may not fulfill the objectives he has set torit. 
For example, if the agency adds an automatic vehicle loca- 
tion system at some later date, computer software modifica- 
tions will be required to perform the location-finding calcula- 
tions, io determine the unit closest to an incident, and to 
drive displays, all of which have an Impact on the digital equip- 
ments and work station layouts. 
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4. PLANNING FOR COMPUTER-AIDED DISPATCH 


The planning proceu cunRUtR of the following baoic 

Rteps: 

(1) Analysis of recuirements. 

(2) Selection of systi'^m configuration and preparation 
of specifications, 

(3) Preparation of impleintptation plan with cost 
estimates, 

(4) Evaluation of expected benefits versus cost. 

The following chapters suggest guidelines for these steps: 
This chapter discusses the overall planning process. 

It must be kept in mind that the process does not consist 
of simply going through the steps defined above and coming 
out with a definitive plan. Planning should always be an itera- 
tive process, which means that one goes through some or all 
of the steps several times. For example, once the requirements 
have been defined and the process of defining tiic system con- 
figuration has been started, it may turn out that the available 
resources will not cover a system that meets the requirements. 
If more resources cannot be found, the requirements will have 
to be scaled down to fit the budget. Another possibility is that 
no single off-the-shelf system will meet ail the requirements; 
one way of solving this problem is to modify the requirements 
to fit what is available. The implementation plan is developed 
in collaboration with user personnel, and during this step it 
may be determined that the requirements already defined do 
not meet tlte needs of the operational personnel. Require- 
ments may have to be added or modified, and the process 
must then be repeated on the basis of the new set of require- 
ments. The cost benefit evaluation in turn may reveal that 
certain features do not appear to justify their cost, or that 
others that have not been included in the plan will actually 
yield a large benefit for a relatively small additional cost. In 
this case too, the process is started again from the beginning. 

The difficult step in the planning process is the first: 
analysis of requirements. This step attempts to answer the 
question; “What is needed In the way of computer-aided dis- 
patch functions?*' Answers are likely to cover the range from 
“We’re doing all right with what we have” or “Our citizens 
deserve the best service we can give them, and we can afford 
to give it to them.” 

It was mentioned above that operational personnel will 
necessarily be involved in the preparation of an Implementa- 
tion plan; in fact, they should be involved from the very 


beginning when requirements are being defined. They have 
one very useful view of what is needed, and In any case they 
will accept a new system much more readily if they have had a 
hand in the process of defining and selecting it. Where a large 
department makes It feasible, it is often a good Idea to try out 
CAD on a small scale, say one complaint operator console and 
and one dispatcher console, to sec whether the requirements as 
defined arc realistic and whether the new system is likely to he 
accepted readily. This trial may well lead to a revision in the 
definition of requirements. 

Since it is never possible to have everything, every 
requirements analysis must include some trade-offs of one 
desirable feature against some otiicr desirable feature. It is 
always desirable to save money, and trade-offs frequently 
involve determining how much capability has to be sacrificed 
to stay within available resources. Typical trade-offs for a CAD 
system miglit be: 

• Number and size of computer files to be created 
and maintained. 

• Simple incident log printoi'ts versus computer- 
processed statistical reports for management. 

• A self-contained CAD system versus one with a 
built-in capability for future expansion. 

• Single versus dual CRT displays (see Chapter 6). 

• Dedicated versus sliared computer (see Chapter 6). 

These are fairly straightforward trade-offs, mostly involv- 
ing money. Other, ntore intangible trade-offs will come up 
during the analysis of requirements; for example, how much 
will a given CAD system decrease the stress on dispatchers, 
and how much is such a decrease worth? Chapter 8 contains 
more discussion of the evaluation of benefits, which necessarily 
enter into trade-off analyses. 

Even when all the steps in the planning process have been 
repeated as many times as necessary to produce a final, realistic 
plan, it should not be expected that the plan will remain un- 
changed up t(» and through the implementation of the system. 
Such implementation normally takes considerable time, and 
many things can happen during that time to require changes in 
the plan. Conditions can change, resources can change, tech- 
nology can change, and even personnel can change to the 
point where the plan will need to be revised. Tire planner must 
always be ready to revise his plan when circumstances make it 
advisable. 
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Chapter 5 provides some Information and guidelines that 
may he helpful in analysing requirements for a CAD system. 
Chapter 6 describes some of the hardware currently avail- 
able for CAD systems and describes some system concepts. 
Tills is a rapidly changing technology, Imwevcr, and the plan- 
ner should not rely on the data presented here but contact the 
various suppliers directly. A partial list of sucli suppliers is 
included in Appendix A. 


Preparation of an Implementation plan is discussed In 
Chapter 7, including procedures for estimating system costs. 
Chapter 8 takes up the question of cost versus benefit analysis, 
which Is made difficult by the many intangibles on the benefit 
side of the equation. Some of the factors that should be 
wolgtied are discussed, and examples arc presented based on 
CAD evaluation reports from the Huntington Beach and Oak 
Park Police Departments. 


5. PLANNING GUIDELINES: ANALYSIS OF REQUIREMENTS 
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The general requirement to be met by a CAD system Is to 
Improve commaiul and control, which is u reahtime decision- 
making process where humans and machines monitor the status 
of field units, receive information on incidents, and assign and 
control units as incidents are worked. The results are both 
reported immediately and stored for later recall. 

Any command and control operation is a decision-making 
process, but a police command and control center is an espe- 
cially busy one. Without taking part in such an operation during 
a busy period, it is hard to appreciate the pace at which vital 
decisions must be made. On a typical busy Friday or Saturday 
night, a dispatcher is making decisions at the rate of two or 
three a minute for periods up to an hour at a time. We want to 
be sure that CAD does not make this very demanding job more 
difficult. 

We have already pointed out that CAD does not neces- 
sarily enable a dispatcher to handle more units or more inci- 
dents. The objective of a good command and control system 
is to enable the dispatcher to make better decisions, and for 
management to have a clear, concise, and up-to-date picture of 
field activities. It does this by helping the dispatcher keep track 
of current incidents and their status and of units available and 
their status, and by providing fast access to other information 
(lies. A CAD system does these things more efficiently and 
faster than they could be done in a manual system. 

The requirements analysis process for a given agency fol- 
lows this sequence: 

(1) Functional Requirements Analysis. Those func- 
tions that can be performed by a CAD system are 
defined, enabling the planner to select a set of 
them for preliminary assessment. Section 5.1 lists 
these functions and summarizes the results of our 
survey of several departments. 

(2) lyorfc Station LoaJ Analysis. In most cases (he 
development of a plan will require a brief survey 
of the volume of calls for service and the patterns 
of incidents. Section 5,2 discusses techniques for 
tnakiitg such surveys. 

(.1) Sy.stem Design f)ecisions. These are determina- 
tions of major system parameters such as numbers 
of positions and files, and how the people manning 
the work stations are to interact with their equip- 
ment. .Section 5..1 presents onr findings on how to 
arrive at these decisions. 


6.1 Functional Requiramenti 

The first step in determining functional requirements is 
to identify those functions that the agency will want the CAD 
system to perform. Since these cover a range from basic to 
highly sophisticated, it may be advisable to list separately tlie 
functions that arc considered essential and those that arc 
desirable but not essential. Then when tlic system specifica- 
tions are being developed they can include the desirable features 
to the extent that resources permit. It should be expected that 
this initial step of defining functional requirements will have to 
be repeated at least once after a system has been defined and 
cost estimates developed. 

As a basis for arriving at a reasonably complete list of 
functions that miglit be performed by CAD systems, we made 
a survey of 1 1 police departments which have CAD systems in 
operation. 

Table 3 lists the range of functional requirements fur a 
CAD system that we found in our survey. Table 4 summarizes 
how these requirements are met fur each of the departments 
surveyed. Some of the significant points to be noted are: 

• All of the cities except Palm Beach County and 
Glendale have a two-stage command and control 
system in which a complaint board operator takes 
the calls and a dispatcher assigns them to patrol 
units. In those cases the dispatcher takes the calls 
directly. 

• Although it is not noted in the table, three of the 
largest cities (New York, Seattle, and San Diego) 
had two types of complaint board operators, pri- 
mary and secondary. The secondary operator 
handles the longer calls. 

• All of the larger cities and some of the smaller ones 
have autotnatic call distribution systems (A('D.S) 
that arc placed ahead of the complaint board to 
route the incoming calls evenly among the com- 
plaint board operators. 

• The job of the complaint board operator is to record 
the caller’s information In a standard fonnat. In alt 
cities surveyed, this is done on the keyboard of a 
terminal with a CRT display. 

• In most cases the complaint board operator is able 
to route a call to another agency if it is not appro- 
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CAD Features 

Complaint board operator (CBOl bandits and anttrs data Into computer, 

Computer adds routine data - strlal number, date, time, operator I D, 

Computar checks data for validity. 

Some systomi have address verification and listing of nearest cross streets by computer. 

Some systems have computer check of prior history file for previous Incidents or other 
data on the address. 

Large systems may have a backup CBO to handle long cells. 

CBO has computerized files of most-used telephone numbers to spaed referrals plus 
other functions (ambulance, tow, queries to remote data bases). 


Computer reformats Incident date from CBO Into dispatcher Incident format, adds 
routine date, and displays on scrsan of dispatcher for the given area. 

Computar also prepares incident summary (ona-llnal end adds to incident summary file 
displayed on dispatcher's Krean to indicate his backlog. 

CAD automatically maintelns status file on all petrol units under dispatcher's control 
and displays file on dispatcher's Kraen. 

Some systems use half screen (or status file, others use separate screen. 

Some systems have computer display list of patrol units nearest Incident address (from 
last reported position) to help dispatcher salact unit. 

Address verification, nearest cross streets, and prior history checks es noted under 
M) above (some sw stems). 

Relay queries to remote data bases (wants and vuarrants, OMV, NCIC) end relay 
responses to patrol unit. 

In some systems with mobile digital terminals In vehicles, petrol units can send queries 
and receive responses directly. 

Where queries ere relayed In control center, some systems use separate information 
operator for this function rather than dispatcher. 

Some systems maintain temporary situation files (traffic, street repairs) end display 
automatically the situations related to the Incident address. 

Dispatcher Is able to locate end assign additional support rapidly. 

Dispatcher can contact other agencias rapidly at needed. Some systems handle such 
contacts through watch commander, dispatch supervisor, or information operator. 

CAD provides for real-time monitoring of vehicle status, essignmentt, time on call, 
breaks, vehicle location. 

Dispatch supervisor or watch commander r-r -unitor entire fleet by calling up dlspleyt 
of all dispatchers. 

CAD maintains continuously updated files of all Incidents - essigned, unassigned, 
cates cleared. 

Dispatch supervisor or watch commander can monitor status of ell incidents by calling 
up Incident displays from dispatcher's consoles or from computer files. 



13 


Pu Milan 


CAD Pmiuim 



• Olipitch by volet or dlglttl; lyitim miintiint radio and lalophona oeilvliy iittlillci. 

• Syitomt with mobita digital tarmlnali ean hava CAD automatically updata patrol unit 
itatui fllai from digital maiHgoi by patrol uniti. 

0 CAD lyitom handlai ill routina oparitloni of log off: data irtd tima of log off, rtmovil 
of Inoldint from Mtivt flit, itoraga In cloiad incldint flit. 

0 CAD tyitom lupporti coordination of multipit unit ind/or multipit tgtncy iiiignminti 
to ont tvtnt. Rtiourct ivilliblllty It ilwayi updittd and vlilbit to tuptrvliory pirionnol. 

o 8omt lyttomi uit tht CAD fMlIittii to ilmpllfy tnd>of*ihift rtporti. For routint cimi, 
offlotr ttlophonai diti ind ricordi dark tnttri data via ktyboard uilng itandirdlxtd 
intrlti. 

o Ptrlodlc rtporti on crimt ttttlitict 'tquirtd by itita livil IBCSI irt gtntrattd by tht 
CAD tyitem from tht Incldint lopi. 

0 Rtporti art ginaritad off'llna at convinlint timii, uilng computer and Itni prlnttr, 


o Stitlitici can bi broken down by any diilrid lit of citigorlii (type of crime, erii, 
time of day, day of weak, ttc.) and computir will lort by thoit catagorlit. 

13. Oipirtmint manigimant rtporti o Dipirtmint managomint rtporti are tlio gtnaratid from CAD computer f llti (Incident 

logi, activity logi for CBOi, dlipatchiri, patrol unlti, officaril. 

0 Any deiired breakdown can be uied. 

o Computir can be progremmtd to flag devlatloni or trendi automatically. 

1 4. Special reporti o One-time rtporti or itudiei of particular crime activity patterni are eaiily generated by 

the computir from the CAD tyitem date available. 

• Studlet of officer or petrol unit activity art eaiily produced from the CAD logi. 


priatc for the police department. Most call distribu- 
tion systems do not disconnect the caller unless he 
hangs up. 

• All departments dispatched by voice, but some also 
have the capability for digital dispatch (a digital 
message to the printer or screen in the mobile digital 
terminal in the patrol unit). 

• In all citlescxcept Dallas and Toronto, a complaint, 
once entered by the complaint board operator, is 
assigned a priority and routed to the dispatcher 
handling the /.one where the incident is located. 

• In all of Ihc systems, dispatchers cleared cases on 
the basis of a voice report from the patrol unit. 

• Dallas, Jacksonville, and (ilcndalc have programmed 
their systems to prodinc niaiiagement reports as 
well as the standard logs. Tho Jacksonville system 


prints out patrol unit activity, manpower alloca- 
tions, and response time. The Dallas system prints 
out activity reports by beat, car, man, and crime 
type. 

• Dallas maintains a backup system of cards in slots 
in parallel with the CRT display for monitoring the 
status of calls for service and the .status of units. 

• I'or split-screen CRT displays, only one display 
screen is provided for the dispatcher, with the area 
divided between the displays of patrol units' status 
and incident status. Must agencies have dual dis- 
plays at the dispatch station, one for unit status 
and the other for incident records. 

In 1975 most of the departments surveyed were in 
various stages of providing computcri/cd tiles to support the 
dispatcher. Huntington Hcach has extensive files giving loca- 
tions of registered gun owners, wants and warrents, and nar- 
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cmicii ana »ex offenaori, Tlifx department In InRtalllng a Deu- 
graphic flic that vorlflc* an addrcttB end Indicates the type of 
premises; the computer also references any microfiche files 
covering the locution (the microfiche files contain, for each 
reporting district, a map of the streets and alleys, the locations 
of sites having alarms, layouts of apartment house complexes 
and bunks, plus other pertinent information). 

Interagency contacts are all handled, us the table Indicates, 
by voice (except for remote data base queries), Although CAD 
offers the possibility of computerized cooperative dispatch for 
adjoining jurisdictions, only limited systems have been worked 
out us yet. lire I’alm Beach County (and other counties in 
Florida) Sheriffs CAD System dispatches for several of the 
municipalities in the county; three municipalities in Illinois 
(Oak Park, Forest Park, and River Forest) are now operating a 
cooperative CAD system. 

Tlie table Indicates that case log-off is usually done by 
the dispatcher. In fact, the procedure varies considerably in its 
details. In Huntington Beach and Glendale, the patrolman dic- 
tates a highly formatted case clearance report to the dispatcher 
and the dispatcher keys in the codes in the appropriate fields on 
the form displayed on the screen, The Dallas procedure is quite 
different; the patrol officer simply Indicates to the dispatcher 
the time a case is cleared and then at the end of the shift dic- 
tates the details to a clerk, who has recalled the incident report 
to the screen and enters the required Information. In all systems, 
the computer generates a complete file of case clearance infor- 
mation for use in statistical reports. 

A range of different reports are generated by CAD systems 
(in addition to activity logs). Some systems generate manage- 
ment reports on Incident rates by area, beat, time of day, etc., 
scheduling of patrolmen for duty, analyses of police operations 
and equipment use, and uniform crime reports (UCR) data. The 
Glendale and Dallassystems produce an extensive set of reports 
for use by taw enforcement managers, including activities by 
shift, day, beat, patrolman, vehicle, type of crime, and other 
variables. Jacksonville produces extensive reports for manpower 
scheduling and resource allocation, 

III no case is a CAD system used for large-scale emergen- 
cies. Tlic practice is to assign one or more dispatchers and 
frequencies to an emergency console, and the assigned units 
arc managed by two-way voice comimmicutions. 


5.2 Work Station Load Analysis 

The second part of tlic requirements analysis process is a 
quantitative measurement of tire operations taking place at a 
typical dispatcher console. This will be useful in selecting a par- 


ticular system on the basis of how well it will help the dispatcher 
handle the expected load. 

In general, conversion to a CAD system may not reduce 
the lunnher of dispatchers needed at any one time. We noted 
earlier tltut a large amount i>f a dispatcher's time is occupied in 
talking and listening, neither of which is accelerated by a CAD 
system in itself, althougit In combination with mobile digital 
terminals a (!AD system cun reduce the average voice message 
Icngtit. 

Tlie basis for u work load analysis is a tabulation of 
message rates aitd message lengths; together these constitute the 
load on the dispatcher. We were unable to obtain good numer- 
ical data in the course of our survey, and decided that it would 
be necessary to make some detailed observations and analysis 
of a real CAD system in operation, Tlie Huntington Beach and 
San Diego departments kindly allowed us to make the observa- 
tions we needed. The procedure was sUgItily different in tlie 
two cases; 

• Huntington Beach. We selected certain periods of 
higli and moderate activity and obtained voice 
tapes of dispatchers plus the corresponding case 
logs. From the tapes we timed voice messages with 
stop watches and elapsed time clocks and estab- 
lished correlations between cases, cars on patrol, 
message rates, and operator utilization, l,e., “busy 
time", 

• San Diego, Here we made videotapes of the dis- 
patcher’s incident display and recorded the voice 
channel. This enabled us to analyze the relation- 
ships between the keyboard and screen operations, 
and the voice messages. 

Tlic dispatcher’s time is devoted to talking, listening, 
manipulating the display scfceii, and reading data; the first 
tlircc of these functions can be measured, and give a reasonable 
indication of dispatclicr workloads, assuming that adequate 
allowance is made for reading and assessing data, making deci- 
sions. and resting. Tiic work load Is affected primarily by the 
number of field units deployed, by the number of calls for 
service in progress, i.e,, dispatches, and by special duties sucli 
us relaying requests for Inquiries to etime information files, and 
arranging for ambulance and tow truck service. In San Diego 
cadi dispatcher handles :i0 to 50 field units, and makes all 
dispatches by voice on assigned radio cliannel. Kacli dispatches 
cases, notes status changes, and logs off cases throiigli tlic key- 
board terminal. Tlic console lias two CRT displays, one fixed 
format for slatusofvcliiclcs.aiid the oilier a variable formal lor 
working incidents. The keyboard has a standard alphaiuimeric 
keyboard willi lb special function keys. All Information 
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iii 4 Uirli»ii for wuniK, wurriinu, uiu) Ntokn v«ltlt<le nnd pmpony 
clieckK ure liHitilUd hy a itpek'lul np^rutitr over u IhcHvuI ehan> 
nel NO thui (he tllKpuielicr In not burdened with thiN duty. 

I-I^ure 2 und Tuhlc ,S Nuininurl/e the work loud unulyNiN. 
During the huNy period in Sun Diego un uverngo of diNpuleheK 
were In progreNN, und dtiring one l(l•lnlnule period reucltcd u 
inuxlimim ol' 25 eiiKes in progresN, Thirty eulU were dUpiitched 
Itiehiding three prlorlty-1 cuIIn, und .D logged off. Tlie cunc 
loud hiNtory Ik kIiuwii in I’lgttre 

Tlic disputcher wuKiniNy Oh.S percent of the time, tulkiiig, 
'iNtcning.undmunipulutiiigthe termlnuliof tliut 9.S percent wun 
devoted to lerminul munipidutloiis. Uusy time during the Itour 
vurled from 55 percent to u tnnximum of 74 percent; on the 
uvcrjgc, 12 voice und termlnul trunNuetions per minute were 
procem'd (u muxiimim of IS trimsuctions per minute wus 
noted). The uveruge voice mcsNuge wun 3.4 seconds in durutlon, 
und the uveruge termlnul trunsucdon, 7 seconds. i*orty>scven 
Held units were deployed during the hour. The disputciter pcr> 
formed u lotui of 799 operutlons during the hour! 

Averuge trunsuction times were noted to be: 

(Seconds) 


Assign unit to incident 3 

Cicur incident 2 

Review Incident 2 

Add new datu to incident record 7 

Send message to anotlier console 10 


In general, the station appeared to be approaching 
saturation under the observed loading conditions, with Instances 
of mobilc-to*base voice message Interference noted, although 


good radio discipline wun muinlulned. A heuvier work loud 
could have heen uccoinmoduted lor u short period of time, hut 
obviously would huve heen very slresNlul to the diN{>utcher if 
KUNtulneil for long perlodN. hiorlti/ution ol culls wus noietl to 
he u very elfective nieuns lot leveling ihe work louds, for both 
the disputcher uod field units, 

I’ortlie I 'hour period of "oormur activity, with .17 field 
units deployed, un uveruge of 1 1 culls lot service were In prog- 
ress with u muxiimim of l.t. I.bspuichet oiill/uiion runged from 
17 to 4 1 percent, for un uveruge ot 30 percent, of wliich Itl per- 
cent wus devoted to termlnul munipiiluiloiis. On the average 
six trunsuctions pe< minute (voice und keyboard) weie 
processed. 

Data polotsfor the Huntington lleuch Uollce Depuitmeni. 
which has a generally similar type of computer-aided dispatch 
system, arc simwn for comparison. In all cases, llie anumnl of 
time spent in manipulating tlic display terminals varies from 
5 to 10 percent, I.e., voice transactions are tlie primary work 
load determinants. The Hunilngluii Deacli Police Department 
tends to have a somewhat htglicr work load averuge per dispatch 
than docs Sun Diego, even though Huntington Reach employs 
mobile digital printers and status indicators; tills would indicate 
that “digital" dispatcliing muy nut displace voice dispatcbiiig 
(and voice radio channel loading) to the exient unliciputed by 
some planners, ultliough more uperutiuiiul experience is needed 
before conclusions can be drawn. The work load does not drop 
to /.eru us Ihe case load uppruuches ?.eto since, as one might 
expect, the disputcher spends considerable time making admin- 
istrative support culls during relatively slack periods.* 

*We wish to estend our sincere upprcclutlon to Captain Ken t-ortier 
and staff of tlie San Diego Police Deparlnieiit. and to Captain 
M. C. UurkenI'leld und Sergeant Robert I'lckle of the Huntington 
Reach Police Deparlinent for their assistance und cuoperatloii In 
obtaining these ineasureinents. 



Pig. 2. Computtr-aidid dlipatehir work lood niMiurtintnti 
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A«lilitionuUuu)ii>Mirk«!y POinmHiiilMiul (loiiirol iniiciloMii 
({Vtiiiciiliirly dl!i|Mk'li Kiuiluiiii) Nlimild k< |)«!rrorni0d in orilpr 
10 |)fovUli< II iH'ltv'r iiiulciNlmulinti oi' iIh* iminuM ot icwdiiioloHlcul 
liiMovHtionN on iIu?kv optMiiiioiiN, Sirvuslitl <r*nvitoimu'iUK kIioiiUI 
111 no wiiy lu< iii«tuiivuli?di perMinniil who luck pooil lyplnii nKIIIk, 
Midi ii» I'idd ol'llccrN Icniporiiilly UMilitncd lo ditiputdi duties 
miiy find It dirt’iciili to peil’oini In u "lypc or pctlnli" 
i'livlronincni, 

The two dcpariincniK observed und reported lierc lire 
representutlveund provide some bush for estimutinrt work louds 
III dhpiitdier consoles, ilie planner slunild consider iiiukini; 
slnilliir nieiisiirenients during a lypiciil busy period, which lx 
the loud tliui deierinines the iiuijo, requirc-iieniH of n system. 
The dutii ttiveii above suggests that a console should be provided 
for ouch dispulcher work station in a nuinuul system; some 
suggestions and recommendations regarding the desirable fea- 
tures of such a console will be found In Chapter 0 . 

The procedure fur making work loud measurements in a 
system willrout CAD is essentially the same us described above. 
That Is, a typical busy period, or several such periods, should 
be unuly/.cd. This is most easily done by replaying a tape record- 
ing of the truffle to and from a given dispatcher, und using a 
stopwatch to determine message lengths. Items that shoidd be 
covered iit the analysis Include: 

• Number of incoming messages and length of euch. 

• Nutnber of outgoing messages and lengtli of each. 

• Case number associated with euch incoming und 
outgoing message (witcre messages are related to 
specific cases). 

• Type of message (status change, assignment of a 
patrol unit, data Hie query, monitoring, and 
support). 

• Number of cases initiated during the observation 
period. 

• Number of cases closed during the observation 
period, 

From such a set ol' observations, It is possible to 
determine some of the parameters of interest for a CAD system 
(as welt as for general management purposes); 

• I.ength of messages by type (status chatige, assign- 
ment to incident, requests from patrol unit, etc.). 

• Kale of messages (incoming plus outgoing). This 
is done by dividing the observation period into 


Miiull xegmenis of S or ID minuiex und counting 
the messugex in each xucli segment, 

• Fereent niili/utlon of dixpuicher’s time. For u non- 
CAD system, this will he the lolul of all message 
limes plus some ullowunce thui will Intve to he 
determined hy ohseivulion for time spent In 
writing, huiulling slips or forms, ele„ wllhoni 
siimdluneons lulking or listening. 

• Average mimher of messuges per cusc. 

• Numher of ineidents being liumlled at one time for 
eiieh .‘i or ID minute segment (this gives the peuk 
loud within tlie hour), 

• Averuge und muximum length of lime from start 
of an ineldeni to the time il is closed (hy inekleni 
priority). 

• Number of puirol units assigned lo the d‘spatchet. 

A review of the duta provided by siicli an analysis will l>e 
useful in evaluating the feuUites offered hy different CAD sys- 
tems and in designing tlie system itself, Such information, 
especially that related to message type, is helpfid in tlie selec- 
tion of keyboard funetions and Ibrmats for screen displays. 
The data on dispatcher utili/:alion and lumiber of simultaneous 
Incidents being Itandled are theptineipal measures of work load, 
althougli tlie mimher of patrol units assigned lo tlie dispatclier 
inlluences the work load. As noted earlier, a CAD system docs 
not necessarily reduce tlie work load as measured in iliese terms, 
but should make a given load less stressful for the dispatclier 
to handle. 


6.3 System Design Decisions 

Once a department has begun considering adoption of a 
C AD system and has carried out the first two steps of deHning 
functional reqiiiremcnts and analyzing the work load, the iieM 
step Is lo make some of tlie essential declsiotisalioul what the 
system will look like and how it will operate. Ilie purpose ol 
this section is to review each element of a CAD syMcm and 
onlllne some of the considerations lliat should inrtueirco such 
decisions. Wtiercver possible, specific riala on the system 
element is presented. 


6 . 3.1 Trunk Line Requirements 
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A pidlce eommand and coiitto! center, manual or with 
CAD, will ill most eases liave a complaint board irpcrator 


(('))()), ulUuHigh ci'iiiilii ilcpui'lmi.'ntK ;:ombini-' this position 
will) thill «it' i]ls|iiiiduH ((ilomlulu iiml I’iilio Hciich Cotinty in 
oiir survey). In dthcr Ciise, the i'nnctUm of lukinit eiilts for 
scrvk'tf front the publle must ho porforinotl. If ti now ('AD 
systont is to ho linplomoi! It may ho n good Idoii to 
rooxiiminc the (MK) position to dolermiito how well it is per- 
forming its fimelion mid whether any modifleations should he 
nuulc ut the lime the now e(|ulpment is Installed. 

This seetion will discuss methods of determining the 
required numher ol' trunk lines to sorviee the (TiO position, 
and the lumihcrs of primary and secondary operators required 
to maintain a given level of service, 

A major system design decision is that of whether or 
not to have a secondary operator position. Figure 4 shows the 
typical How of calls through a compiaint hoard system having 
a secondary operator position, although the first part of the 
flow is the same in citlier case, (’alls from the public are auto- 
matically connected to an available trunk line us long us they 
are not all occupied (In this case the culler receives u busy sig- 
nal). The incoming calls all go to the automatic call distributor 
system, which attempts to find an available primary operator. 
Ifnone is available, the call is placed in a queue until a primary 
operator is free to receive tlie call. 

Those systems having secondary operators use tliem to 
handle titc longer calls, generally those a minute or lunger in 
duration. The primary operator receives alt calls first, and 
decides which should be transferred to the secondary operator 
(or to some other city department). In all cases the incomiitg 
call continues to occupy a trunk line until the caller hangs up. 
even when the call is transferred to the secondary operator or 
another department. 


Tire procedure lor determining the numhrr of trunk lines 
and operators needed is us follows; 

( 1 ) The planner specifics the performai.ee level desired, 
in ternrs of whut peiveniage of calls are allowed to 
receive a busy signal, and what mean waiting time 
is accept able. 

(2) The planner measures (or estimates) the peak call 
rate to he handled. 

(.1) The design curves sliown In this section are used to 
derive the required numbers of trunk lines and 
operators. 

Typical performance speciUcations arc in the following 

form: 

( 1 ) No more than ^ calls out of each 1 000 shall receive 
a busy signal. 

(2) The average walling time for a call placed in the 
primary operator queue shall not exceed 2J sec- 
onds. 

(2) The average waiting time for the secondary operator 
shall not exceed 20 seconds, 

Tile numbers entered in the “blanks” above are typical; 
the planner should establish these for his own system on the 
basis of his own measurements of peak loads, and his estimates 
of how frequently a given call rate might be exceeded. 



Fig. 4. Complaint board operator call flow 






As purl nfhlsineiisurcmciii ol'ciill rate, liie planner shmilU 
liave colleeicd data on call duruilirns. He Is tlien in a posiliitn 
to ileierniiiie peak loadln|< on ilic titink lines as lollows; 


Trtmk work load 


Peak call rate (calls/hour) X call 
duialion (sccl 
>V)0() 


As an example, suppose that on a busy l-rlday nislil a 
police deparliuoni is iccclvinn -00 calls per hour and lire culls 
arc serviced in 1 50 secomison the average. .Service time includes 
the total time the call was in tlie system, including any time 
spent in t|ueue waiting for cither tlie primary or secondary 
operator (plus the time spent talking with either operator or 
with anotlier city department), in tlris case; 


nressage flow to the itrlglnal 0..5 percent busy signal specillca- 
ti*m becomes 14 once more. With both changes (5 percent 
Inisy signals, 120-second calls), the number of trunk lines 
retiuired liecoines only 1 1 . 

6.3.2 Primary Complaint Board Operator Poiitioni 

'l ire procedure for determining the numlret of primary 
complaint board operators needed is similar, but in this case 
the performance parameter is the average waiting time before 
the caller is connected to a primary operator (l.e.. the average 
length of time a call renralns in the At'US queue before the 
ACDS can find an available primary operator), Ibis delay will 
naturally be shorter if there are more operators, but more 
operator time would be spent waiting for calls. 


200 X150 

Trunk work load = — = b.33 load units 

3600 

Now the curves of I'igurc 5 can he liv'd to determine the 
numirei of trunk lines needed to handle this load with the per- 
formance already specilied. I he value ol (. (the number on each 
curve) is the number of trunk lines. 

Referring now to l-lgure 5, we note that our requirement 
for not more than 5 calls per thousand receiving a busy signal 
translates to 0.5 percent, which is the lowest horizontal line. 
Following along this line to the value of 8.33, we take the 
nearest value of C to the right, which is 17. This is the number 
of trunk Hues needed to meet our specifications indcr our 
peak load conditions. 

It is of interest to note the effect of changing some of 
the parameters. For example, if the percentage of calls receiving 
busy signals were increased from 0.5 to 5 percent, the number 
of trunk lines needed to meet the same demand becomes 13, 
And if the average call duration becomes 120 seconds rather 
than 1 50 seconds, the number of lines required to handle the 


For our purposes, delay units are obtained by dividing 
the average waiting time by the average measured service time 
(lime the operator takes to handle the call, not including wait- 
ing time): 

mean waiting time in seconds 
Delay = j*ican operator service time in seconds 

The operator work load is then calculated as: 

( peak call rate (calls per hour)\ 

X mean service lime in I 

seconds ' 

Operator work loau ~ 

Retuniiiigtoour previous example, we have calls arriving 
at the rate ol ' 00 per hour and the average service time per call 
is 100 seconds. We have specified that the average waiting time 
shall be no more than 2.5 seconds, so that our number of delay 
units is; 

Delay unit = 2.5/100 = 0.025 



The operator work load, calculated as shown, becomes; 

Work load = 200 X 100/3(r00" 5.56 load units 

Now we turn to Figure 6 to find the number of primary 
operators required to handle this load with no more than the 
specified average wait. The 0.025-delay-unlt line tuns horizon- 
tally near the bottom of the Dgurc. It intersects the vertical 
5,56-load-unll line at the point shown, and we take the nearest 
curve to the right as before. This Is the curve for 10 primary 
operators, which is the number needed. 


Once again.it is interesting to note the effect of changing 
the parameters. If the specification for average waiting time is 
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glmiincil iVoni '.5 stvitiuls t*i S smMuls, I'or i.‘.Siinipk’, (lie ileliiy 
unit viiUie lifcoim's: 

S/|l)() O.OS mill 

iiiul tlio inlcvsoeiion ol' lliis value wiili (lie same woik load falls 
between (lie curves for i< ami ‘J operiilois. iiiakiiin (lie reciuireil 
number Ami if (lie averane operalor service time ilroiis |■rolll 
100 secomls to (i0 secomls. (lie work load becomes; 

200 X 60/:t(*00 == units 

and only 7 opeialors arc needed to maintain the 2.5 second 
average waiting time. 

5.3.3 Secondary Complaint Board Operator Poiitions 

Not all departments use a secondary complaint board 
o]ierator to liaiidle the longer calls, but some liavc found it a 
good way to improve service to the public and reduce the work 
load on (lie primary operators. In calculating the number of 
secondary operators needed, we note first that all calls going to 
a secondary operator must first go through a primary operator. 
If all secondary operators arc busy, there is a waiting time 
tluil must be added to the waiting time required for the caller 
to reach the primary operator. The waiting time tor the second- 
ary operalor will naturally depend on the number of secondary 
operators. 


We ciilcnlate the nimiber of secondary operators needed 
ill the same way as for the primaiy opeialors. calculating the 
delay and the woik load and finding their Intersect ion point 
on I'igme b. 

first, however, we need to define what kinds of calls arc 
to be handled by tlie secondary operator. We will define “long" 
calls as those that require more than oO seconds to service and 
which do not require dispatch. All other calls (namely those 
that either require dispalcii or lake less than bO seconds) are 
defined as “short" calls. 

In our sample spccif'cation, we indicated a maximuni 
average wailing time for a secondary operator as 20 seconds, 
f'or our example of a department witli calls arriving at I lie rale 
of 200 per hour, let us assume that 5 percent, or 10 calls per 
liour, are “long" calls that arc to be transferred to tlie second- 
ary operator. We will assume further tlial tlio mean service time 
of the secondary operator is 5 minutes (.100 seconds). Now onr 
delay calculation is; 

Delay » 20/.100 = O.Obb unit 
and our work load calculation is; 

Work load = 10 X .100/3b00 = 0.8.1 unit 

On figiirc b, we find the intersection of ibese two values in the 
area between the curves for 2 and .1 operators, meaning that we 
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will need ^ sccomlury opeiainrs Kj Iwmile thU lotitl without 
Icltinfttlic uvcDigc wuiting timi; exceed 20 secondij. Uecuusc the 
curve tor 2 opeinlov!! is so steep, increashtg the sllownble wult- 
lug time docs not change the result drumullctttly; even for a 
waiting time of 60 scc>)nds, 3 operators are still needed. Simi- 
larly, reducing the percentage of “long" calls to, say percent, 
docs not reduce the requirement for 3 secondary operators. 
Reducing the average length »>f a “long” call to 2.5 minutes, 
however, makes 2 secondary operators adequate for nearly any 
specification of average waiting time. 


I'or the l-i>pcrator case we need an average service time 
for all calls, which is 05 percent at 100 seconds plus 5 percent 
at 300 seconds, or NO seconds. Now we compute the work 
loads: 


Work load on primary operator ” ® 

3600 

10 X 300 , 

Work load on secondary operator = “-j,— — =0.83 unit 


5.3.4 Declilon on Use of Secondary Complaint 
Board Operators 


Work load on single operator 


200 X no 
3600 


= 6.11 units 


The determination of wlietlier secondary operators 
should be included in the command and control system can be 
made whether or not a CAD system is to be installed. Since alt 
positions, primary and secondary, must be equipped with 
CRT/keyboard consoles in a CAD system, the additional cost 
of procuring and installing the additional consoles may be a 
special consideration for CAD systems. 

In order to make a quantitative comparison of a system 
with and without secondary operators, the following parameters 
must be measured or estimated: 

(1) Average arrival rate of “short” calls. 

(2) Average arrival rate of “long” calls. 

(3) Average service time of “short” calls. 

(4) Average service time of “long” calls. 

The maximum average waiting times must also be 
specified for both types of calls, as in the previous cukulutiuns. 
in the 1 -operator case, only one average waiting time can be 
specified, since in this case there is no distinction between 
"long” and “short” calls. 

The comparison Is made by calculating the loads on the 
two types of operators in the 2-operator case, and on the one 
type of operator in the 1 -operator case. The curves of l-igure 6 
arc used once more to determine the numbers of operators 
needed in both cases. 

We cun use the same figures for message rates and types 
as in the previous examples: 


The delay units will be the same as previously for the 
primary and secondary operators (0.025 for the primary 
operator and 0.066 for the secondary operator), assuming the 
same specifications of 2.5 and 20 seconds for maximum aver- 
age waiting time. For the single operator tlie 2.5 second speci- 
fication is the same, and the delay unit value is 0.023. Now 
from Figure 6 we find the following requirements for the two 
cases: 


Operators 

2-Operator System 

1 -Operator System 

Primary 

10 

11 

Secondary 

3 

-- 

TOTAL 

TI 

TT 


This means that two additional operator positions are 
needed, but the number of primary operators is reduced by one. 
Whether this trade-off favors the 2-operator system or not will 
depend on the costs involved for the two types of operators and 
on the anticipated improved service with secondary operators 
in the system. 


5.3.6 Dispatch ar Position 

Functions 

lire dispatcher is ul tlic core of the police command and 
control operation, responsible for coordinating the patrol forces 
to meet the rapidly changing demands fur police service. This 
coordination primarily takes tlie form of receiving and trans- 
mitting messages that fall into tivi? basic categories: 


Call rate 

Percent “long” calls 
Service times 
“Short” calls 
"Long” calls 


200 per hour 
5 

100 seconds 
300 seconds 


• Messages involving initial assignments of cases. 

• Messages supporting cases in progress. 

• Messages supporting units on patrol. 

• Messages involving case dispositions. 
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• McxKUgttM rcluying quericH to remote data hmikn and 
the answers to tlicsc queries. 

The first category of messages covers tlie activities of tlie 
dispatcher when a case first arrives at the dispatching position: 
tlndingan available patrol unit, giving tliat unit the address and 
detuiis of the case, assigning the unit to the case, ami entering 
this data into tlie computer througii the console keyboard. 

The second category, supporting cases in progress, 
includes messages from assigned patrol units sucit as status 
changes, requests for verification of address ui location of 
informant, request for backup unit, or additional case informa- 
tion to be entered into the computer file. 

The third category, support of units on patrol, includes 
status messages, handling requests to talk to other patrol units, 
clearing requests for meals, and general administrative func- 
tions not related to specific incidents. 

Tltuse messages related to case disposition include tlic 
case clearance messages from patrol units, any comments on 
the case, and status changes for units involved in the case. 

The last category of messages has to do with requests from 
patrol units, botli on patrol and on assignment, for informa- 
tion from remote files; most sueh queries are for license plate 
checks or wants and warrants checks. 


ruble $ indicates that the llungtinlon Hcach dispatchers 
were busier on a per car or per case basis than the San Diego dis- 
patchers; this results in part from tlie fact that they liundle data 
base qiteries. In the busiest hour for both departments llic 
Huntington Hcach dispatdicr was handling 22 curs and 
I i cases witilc the Sun Diego dispatciicr was handling 47 cars 
and 2.S cases. TItc consequence cun he seen in the "busy time" 
column, where the San Diego dispatdicr was busy almost 
()7 percent of the time wiiile liic Huntington Bcacli dispatcher 
was busy only 40 percent of tlie time. 

We were able H observe tliat when the dispatcher 
"busy time” reaches a value of around fiO percent, ilic stress on 
the dispatcher becomes severe and tlie result is tliat tlie dis- 
patdier begins to defer action on calls tliat are perceived to be 
of lower priority (whether from patrol units or from tlie com- 
plaint board) and to shorten messages. Field units are also 
observed to reduce their demands on the dispatcher during 
peak load periods. Ncvertlidess, the dispatdicr is faced with 
slmultanenus demands that cannot all be met, and must deckle 
among conflicting demands. Tiiis can place the dispatdicr under 
great stress. We feel that (>5 percent "busy time” readies or 
exceeds the peak limit tliat should be allowed for the design of 
a system. Sufficient stations should be installed to keep “busy 
time” to approximately .10 to 50 percent during peak periods 
such as E’riday evenings. 

Simulation 


The data we obtained during our observations of the 
San Diego Police Department were analyzed with respect to 
these categories. For busy liours, the distribution was as 
follows; 

Percent of Total 


Initial assignment 

26 

In-progrcss case support 

44 

Patrol support 

15 

Case dispositions 

15 


On the basis of out observations at Huntington Beadi 
and San Diego, and using the statistical data we collected at 
those departments, we were able to construct a computer 
simulation of a dispatcher work station. The purpose of the 
simulation was to permit us to determine tlie effect on dispatch 
output parameters of varying tlie work load, I’ho parameters 
luuidicd by the simulator are: 

Input Parameters Output Parunietcis 


In addition to titese messages, queries to data bases were added 
in proportion to the number of patrol units deployed, an 
average of t query per 2 iiours per patrol unit. 

The data on dispatcher activity collected from the 
Huntington Beach ami San Diego observations, presented 
graphically in Figure 2, was given in sliglitly different form and 
with some additional measures in Tabic S. This data, pins tlic 
above message classification, served as the basis for our simula- 
tion of a dispatcher work .station. Before we describe tlie s'.rmila- 
tion and its results, however, some general comments are in 
order on our observations of dispatcher activity. 


Operational procedures 
Message types 

Distribution gf message 
types 

Cali urtivul rates and 
time disttibutioti 

Service times and 
distribution of service 
limes 

Number of cars per 
dispatcher 


Dispatcher busy time in 
percent 

('omimmicatioii cliamiel 
utilization in porcenl 

Waiting time forUls- 
patclier 

Waiting lime lor coni- 
miiiiiaition cliaiincl 
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The vmIutioiiK In operational procedure that were 
conaidered were; 

• Queries to remote data banks liandled by dispatcher 
or by separate information operator. 

• C'omplaint board operator and dispatcher positions 
are combined or separated: dispatcher takes culls 
from public and performs dispatcher functions as 
well, or culls first go throu^t complaint board 
operator. 

Tire three variations of these procedures that we selected 
for simulation were; 


System A 

Separate CBO and dispatcher; dispatcher 
does not handle queries to remote data 


bunks. 

System B 

Separate CBO and dispatcher; dispatcher 
handles queries to remote data bunks. 

System C 

Dispatcher takes calls from public, but 
does not handle queries to remote data 


bases. 


The load on the system was in the form of varying case 
arrival rates. Since our analysis of message types showed that 
only 15 percent of messages are not case-related, this seemed 
the most effective way of loading the system. We used the 
distributions of case durations that we had observed. 

Figure 7 shows the effects on dispatcher busy time and 
on channel utilization of varying the case arrival rate from low 
to higli demand, for the three systems analyzed. Both the dis- 
patcher busy time in percent and the channel utilization rate 
In percent are shown. 

We have already noted that a SO percent busy time is all 
that should be expected of a dispatcher (recognizing that there 
will always be short-duration peaks well above this value) even 
during a peak load period. The shaded line across the chart at 
this point serves to identify the points at which the load curves 
cross this limit. Likewise, a 30 percent channel utilization rate 
is about the maximum tliat should be allowed because above 
this value waiting times for a channel become too higli (as will 
be shown in the next figure). A shaded line across the graph at 
this value again helps to identify the points where the different 
load curves exceed this value. 

The major points to be noted from this figure are: 

• riie load curves cross the tw<; limits at approx- 
imately the same points (cases per hour): 




Fig. 7, OlipiMhar ind ctiinnal utllltition vt tyitam load 


Busy Time Limit Channel L.imit 
System A 26 23 

System B 8 8 

System C II 

• The slight differences are toward the channel limit ; 
that is, this limit is reached before the busy lime 
limit is reached. 

• System A (dispalchcr liandics no citizen calls or 
queries) can tolerate a much larger load before 
exceeding design limits. 

• System B (dispatclier liandics data base queries) 
leads to more rapid rise in load as case arrival rate 
increases than either of the otlier systems. 

• The relationship is linear In both cases; the increase 
in busy time or channel utilization is proportional 
to the Increase in case arrival rii»e. 

Figure 8 shows the results of the simulation in terms of 
how waiting time varies as the case atrivil rate increases. The 
most obvious difference front tlic previous figure is tliai tlic 
rclationsliip is no longer linear; in all cases the waiting time 
begins to rise more rapidly as the load increases, i liis is most 
dramatic in Ihe case of System C; at about 8 cases per hour the 
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Fig. 8. Wilting timii vi. cm irrivil riti 


waiting time begins to rise so rapidly that this is obviously the 
limiting rate for this system (note that it is lower than limit 
imposed by a 50 percent dispatcher busy time limit from 
Figure 7). 

System B also shows the start of a very rapid rise at 
about 1 1 cases per hour. This is the point at which the curve 
for System B crosses the 10-second waiting time line; 10 sec- 
onds is the maximum average waiting time specified for the 
proposed nationwide 9 1 1 emergency network, and is about the 
maximum that a patrolman should be expected to wait to 
reach a dispatcher. 

System A reaches a much higher load rate before the 
10-second lino is crossed, but the rate is again somewhat lower 
than the point where the dispatcher busy time limit is reached 
(about 21 cases per hour). 

System C is above the 10-second tine even for low load 
rates because the dispatcher is taking calls from the public and 
these tend to be much longer than communications with patrol 
units. Nevertheless, the rise in waiting time is steep when the 
case arrival rate reaches the critical point, about H cases per 
hour. 

From the point of view of the system planner, the 
important result of this simulation is that with any of the sys- 
tems simulated there is a critical point in the case arrival rate 
beyond which performance degrades seriously either iiecuiise: 
(a) the dispatcher is unable to handle the increased load witli- 


mit being subjected to undesirable stress and reducing the 
level of service and (h) walling limes become excessive, which 
degrades system performance because patrol units cannot com- 
municate with the dispatcher satisfactorily. Channel ulili/.atlon 
could also become a limiting factor at slightly higlicr rales If 
these other factors did not impose their own limits. 

To summari/.c, there is a critical case load value that 
should not he exceeded. Taking into account both the dis- 
patcher busy time limit and tlic waiting time limit, these critical 
case loads as shown by the simulation are approximately; 

rases per Hour 

System A 2 1 

System B 1 1 

System C 

These figures alone would suggest that System B and 
System C are about equal, but there are significimt dilferences. 
it was shown in Figure S that tite channel ulili/.ation remained 
very low for System C at all points; this is due to the fact that 
the dispatcher is taking calls from the public; these arc relatively 
long calls and use no channel time at all. Note also that in our 
simulated System C the dispatcher does not liaudlc remote data 
base queries, as is the case in System B. If the dispatcher had 
this added load, System C would be out of the question except 
for very low case loads. 

The conclusion is that the first step to be taken to 
Increase the capacity of a dispatcher position is to separate the 
CBO function from the dispatcher function. This not only frees 
a large amount of dispatcher lime, but reduces the stress on the 
dispatclier because he is no longer required to deal with the 
public as well as manage his patrol units. He can coiiecntrate on 
the dispatching job, which has enough stresses of its own in a 
large command center without the added stresses involved in 
taking calls from the public, 

Another important function of a separate (’BO is to 
filter calls from the pulilie; some fraction of these calls do not 
require a response from police or other emergency vehicles, but 
If the dlspiilcher lakes a call directly he must do the filtering 
at the expense of. his other functions. The separate (‘BO can 
also Improve public relations if a busy dispatcher Is unable to 
give as much time to a caller as tlic caller would like. 

There arc two ways in which tlic handling of remote daoi 
liasc queries can he separated from the dispatcher function. 
One is to have a separate position for this fuiidton. as in San 
Diego. This is a relatively simple change to make, and the 
intbrmation operator can keep track of other situations such as 
tow requests and aiuhulance recgicsts. 


27 


T 


T' 



i 


1 

I 

i 


The other possibility becomes uvitilnble when the patrol 
units are equipped with mobile digital terminals. With suitable 
software and equipment in the command and control center, 
queries to remote data bases (normally Department of Motor 
Vehicles and N(.'IC, which are already compute ri/.ed) cun be 
relayed automatically from patrol unit to remote data base 
ano liack, with no loud on the center personnel. 

In either case, the simulation results indicate that the 
capacity of u dispatcher position can be increased substantially 
by removing this function from it. 

It is relatively simple to determine the number of dis- 
patchers needed fur u given center. Since the system should be 
si/cd to handle the heaviest expected load, the number of cases 
in progress during one or more of the busiest hours should be 
counted. I'hls becomes the load to be handled. Now the max- 
imum allowable case loud per dispatcher is determined; the 
figures given above from tlie simulation are good starting points 
for this determination. The planner can modify these if he 
feels it is appropriate in llglit of conditions in his department, 
or he may have some combination of functions that does not 
correspond exactly to one of the three systems modeled. 

As an example, let us assume the planner expects to have 
a System A configuration where the dispatcher handles neither 
calls from the public nor remote data base queries. Our simula- 
tions (and our observations) indicate that with tliis systemone 
dispatcher should not be expected to handle more than 25 
cases per hour. We will assume that the case load during several 
busy hours has been counted, with the maximum load to be 
planned for amounting to 80 cases per hour. The number of 
dispatchers istlien; 

Case load _ 80 - j 2 
Cases per dispatcher 25 

wliich means 4 dispatcher stations will be needed. 

Tlie above analysis of dispatcher work loads can be 
summarized us follows: 

• Only In u small department with low maximum 
case loads is It practical to combine the CBO and 
dispatclier functions. 

• Relieving ttic dispatcher of the task of handling 
data base queries makes a sigttiiicant increase in dis- 
patcher capacity for managing patrol units and 
monitoring incidents. 


• Dispatcher loads sitnuld be sized to keep the 
average maximum busy time to about 50 percent 
(with this average, there will he short-term peaks 
when the dispatcher is well above ibis figure), 

5.4 Human Factors Coniiderationi In the Design of 
CAD Systems 

In selecting a system design, the planner ntust consider 
u number of factors in addition to the matter of sizing the 
system. In the course of our observation of police command and 
control centers, particularly those operating under peak loads, 
we noted several ways in which the details of the console hard- 
ware and software affected the efficiency with whicli the dis- 
patcher operates. Since a major concern in connection with 
dispatchers is the stress under which they necessarily operate, 
any efficiency improvements that can lessen this stress should 
be carefully examined. 

We have already seen that a SO percent average busy 
time is tlie must that should be expected of a dispatcher even 
during peak hours. In planning for a new CAD system, it is 
probably advisable to design for an average of 30 to 40 percent, 
or perhaps a corresponding figure of nut more tliun 20 cases 
per dispatcher (including both backlog and assigned cases). 

5.4.1 Configuration of Displays 

In the design of the console itself, it is important to 
avoid overloading the human capacity for accepting and pro- 
cessing information. A dispatcher in a CAD system is handling 
information in four different ways, more or less simultaneously 
or in very rapid shifts from one to the other: listen, talk, read 
the display, use the keyboard. 

In the conventional manual dispatch system, the dis- 
patcher normally performs in a listen-talk mode, with a min- 
imum of manual-visual tasks. Hence, the CAD environment 
imposes additional manipulative functions on the dispatcher, 
which can add to the stress level if nut carefully engineered. In 
fact, the dispatcher is in a "type or perish” environment, which 
can be particularly stressful to field personnel who are rotated 
Into the dispatch center occasionally and do not have a higli 
level of typing skill. The console must be designed to help him 
perform the manipulalive kinds of processing in the most 
efficient and least stressful manner. Tlie voice communications 
with the patrol units can be made more etTicIcnt by digital com- 
nuinicattons, but appear to be indispensable. CAD may help 
reduce the length of some voice messages, but the total talk- 
listen time is not changed significantly. The displays and the 
display formats, however, can intiuence the ctficicncy of the 
console-related functions. 
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The mitjwr design dcdsUin to be made Is lliat regarding 
the number of screens on each console. The data In Table I on 
existing t;Al) systems Indicates that several of them make use 
of split-screen displays, where half of the screen Is us«l for dis- 
playing patrol unit status and the (Mhcr hall l»>r the current 
Incidents or other displays. One dcpariment that begun witli 
a split-screen CRT display has since changed to a two-screen 
display, having found that a single screen docs not provide the 
dispatcher with enough room to display the Information needed 
for rapid, efficient decision making. 

liven two screens may not be optinuim. With a two-screen 
console, there will typically be four sots of data displayed; 

(1) Status of up to 40 or 50 patrol units (a separate 
screen on a two-screen console). 

(2) One case in full detail (6 to 10 lines of a display). 

(3) Summaries of the cases In progress, giving at least 
the case number, type, and the patrol unit assigned 
to it; there may be as many as 30 or 40 of these 
summaries. 

(4) A one-line summary of the higlicst priority incidents 
in the dispatcher’s backlog, giving for each tlic time 
of the call, the priority, case type, and address. 
Tliere usually is room for as many as five of these 
backlog cases. 

Tlie dispatcher can call up to the screen any information 
that is in the computer's memory; in particular, he can display 
the complete backlog or any part of it, and lie can call up the 
complete 10-line format for any case in progress if he needs to 
determine (for example) what patrol unit is assigned or to add 
or change data on the basis of a report from a patrol unit. 
This is a convenience, but at times of heavy work load it takes 
time to key in the necessary instructions to the computer, and 
the information that is called up has to displace some other 
information on the screen. Tlie dispatcher’s task is easier it 
the most frequently used data remains continually displayed, 
with room left for calling up otlier data from tlic memory. 
Three and even four screens can he used effectively to make the 
dispatcher’s task easier by cutting down on the manipulations 
he must perform to display tlie Information he needs for decis- 
ion making. 

This Is not the same as providing the dispatcher with more 
information; it simply makes the information more readily 
available. Cute should he taken not to flood the dispatcher 
with mote Information than lie can use, or that lie can use 
under peak load conditions. Some designers of automatic vehi- 
cle location (AVL) systems have proposed a display showing 
continuously the locations ot patrol utiits on a map ol tlic 
city. Tills is a very sopliisticatcd design and would be useful for 


Slime purposes, hut il would place an additional burden on Ihe 
dispaichcr by coiifroniing him with an overly busy display, If 
AVI, is available, the compiiler should delermlne the patrol 
unit closest lo an incident, and display only Ihe unit iiuin- 
bei(s), which Is all ihe dispalcher needs or wuni lo know. 

In some cmiimund and control centers, a separate ter- 
minal Is used for transmitting queries to remote data bases. 
Such an amingement may he the rcsiill of separate procure- 
nieiits of tills capability and a CAD system, bm the planner 
considering a now (’AD system should avoid II. It is relatively 
simple to incorporiitc the remote data base query capability into 
tlic displuy/keyboard terminal used for tlie GfO and dispatch 
positions. If the dispatcher (or CUO) makes data base queries, 
his job is simplified If he can simply pusli a key instead of 
turning to a different console. 

6.4.2 Display Formats 

There arc many possible ways to display the Information 
a dispatcher needs, and no single set of displays and display 
formats will be the best for all departments using CAD systems. 
From the human factors point of view, formats are very Impor- 
tant; the way the Information is presented can make a very 
large difference in tlie efficiency witli which a disputclier works 
and the amount of stress imposed on him. 

Tlie Ideal way to develop a set of display formats for a 
planned CAD system would be to design a set ot formats and 
experiment with them, making modifications until most of the 
people who will be using tliem are satisfied. If this can be done 
on some kind of a simulation facility before the system is 
installed, the system startup will be easier. liven in this case, 
however, it sliould be expected that there will be some changes 
in format after the new CAD system is implemented, Such 
changes require inodincation of tlie software and tend to be 
expensive, but tliey sliould be planned for because tliey are 
almost certain to be needed. 

A simulation facility would be too expensive for any 
but the largest deparlmcnts, but it would be possible for a 
number of departments in llie same area to develop such a 
facility jointly. This would permit dispatchers to try out dif- 
ferent formats under simulated higli-load conditions, to see 
which were best for their particular situations, 

As CAD systems become more numerous and more 
widespread, it Is possible that vendors will offer standard soft- 
ware packages that Include standardized formats lot displays, 
In tliis case, the planner will need lo consider tlie tradc-ofi 
between tlie lower cost of standardized display formats and 
tlic advantage of having formats specifically tailored to tlie 
needs and/or wislies of iiis dispatclicrs. 
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One way out of thii pociibly difficult choice it the uie 
of to-cttllod “(mart*' tormlnalt. Thoio are coniolei with a buUt*ln 
microproceitor (a very imall computer), and they permit 
change* in display software, particularly special functions and 
displays, much more easily than is the case with the usual type 
of displays, which have fixed display formats and function 
keys. The Shreveport Police Department has used “smart" 
terminals to great advantage, and they cun be expected to 
become increasingly available for new CAD systems. 

In tlie previous discussion of display configurations, we 
mentioned the desirability of having two or three separate 
screens on each console, so that certain kinds of Information 
can remain on view at all times. WIten the dispatcher must use 
one screen, or part of a screen, to look at any one of several 
different displays he can call up from the computer memory. It 
Is called “paging", in the sense that he pages through the mem- 
ory much as one would page througit a book. 

In a manual system, a dispatcher normally has more 
information permanently on view of front of him than Is the 
case in a CAD system. When the CAD dispatcher calls up a new 
display on the screen, or portion of a screen, the information 
that was already there disappears and can no longer be consulted 
at a glance. Therefore, the selection of those categories of 
information that are to remain continuously on view and 
those that must be paged through (called up one at a time) is 
quite important, and the number of keys that must be pushed 
to call up a given display is also important in system design. 
Specific examples of display formats will be given in later 
sections. In the previous section we saw that the four categories 
of information usually visible to a dispatcher, either on multiple 
screens or a split screen, are; 

• Patrol unit status. 

• One-line summaries of cases in progress. 

• One-line summaries of cases in the backlog (or as 
many of them as the screen can hold). 

• One case in full detail. 

We also noted that the dispatcher can call up the full detail of 
any case If he needs to consult it fur information or add Infor- 
mation to it, as when the case is cleared. Other displays he may 
be able to call up include: 

• Remainder of backlog not shown on screen (if any). 

• Vehicle stop. 

• Remote query. 

• Request tow or ambulance service. 

• Message file. 


• Porsunnel file. 

• Assigned duty roster, 

® Display map of sector (If there it an automatic 
vehicle location system). 

Some additional data on how display formats and paging 
can affect the dispatching operation Is ^ven In Appendix B, 
which Is a scenario for an armed robbery In progress us It would 
be handled by the Huntington Beach CAD system. Display 
formats are shown In detail in Chapter 6. 

6.4.3 Keyboards 

The keyboard is the means by which the dispatcher enters 
data into the system, controls his displays, searches files, or 
gives other commands to the computer. He also uses It to send 
messages to patrol units If they are equipped with mobile dig- 
ital terminals, or to transmit messages to other computerized 
systems (e.g., query messages to remote data bases). 

A typical keyboard is shown in Figure 9. A console key- 
board has a nucleus of keys that are much the same as a normal 
typewriter keyboard, plus a number of special function keys 
that can vary (normally) from 1 2 to 20. 

The design decision to be made is primarily how many 
special function keys should be provided. The trade-off involved 
is roughly the following; 

• One special function key replaces a coded sequence 
of letters and/or numbers that would have to be 
entered on the regular keyboard. For example, a 
touch on the LOG OFF special function key, plus 
the number of the case to be logged off, tells the 
computer to locate and display the record of that 
case number, with the cursor automatically pos- 
itioned in the “case clearance” field on the format. 
Tlie dispatcher then simply enters the clearance 
code and the job is done. TItis saves the valuable 
time of a busy dispatcher, provided the dispatcher 
dues nut spend time hunting for the special func- 
tion key. Dispatchers with good typing skills nor- 
mally can command displays using cither regular 
or special function keys with equal speed. 

• The more special function keys there arc, the mote 
of them the dispatcher has to remember and be 
able to locate quickly. Unless a special function 
key is used often. It may not be advantageous to 
have it. Large numbers of special function keys are 
expensive to build into the console and both dif- 
ficult and expensive to change later. 
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FUNCTION KEY DESCRIPTION; 


FI 

ENTER MESSAGE 

F5 

ASSIGN UNIT 

: f2 

DISPLAY MESSAGE 

F6 

ASSIGN STATUS 

1 

ENTER COMPLAINT 

F7 

REASSIGN 

i F4 

DISPLAY COMPLAINT 

F8 

DISPLAY STATUS 


Fig. fl. Shrmtport PD diipiMhgr ktyboard 


It should be understood that the computer is doing the 
same thing whether the command Is entered by means of one 
special function key or a sequence of symbols typed on the 
regular keyboard. In the log-off case, the alternative to the 
special function key is to have the dispatcher type L 0 on the 
keyboard, plus the case number. Then when the computer 
locates and displays the case record, the dispatcher positions 
the cursor himself to the proper place on the format and enters 
the clearance code. In both cases the computer is finding and 
displaying the record and entering the clearance code in 
response to the keyboard input of the dispatcher, and filing 
the record away again. 


5.5 Other Parionnel Requirementi 

We have aircady considered the determination of num- 
bers of complaint board operators, secondary operators (if 
used) and dispatcher positions. 'Fliis section considers the 
requirements f^or supervisors and information operators, and 
presents a brief discussion of the types of personnel to be used 
for dispatching. 


6.6.1 Supervisory Stations 

A police command and control center of any sixe (i.e., 
one with three or more dispatchers on duty simultaneously) 


usually has supervisors to monitor the operations and provide 
overall management of the operation. In large departments 
there may be separate supervisors for the complaint board 
operators, the dispatchers, and the overall command and 
control center. Smaller departments frequently combine these 
functions and need otily one or two supervisors per shift, 

Tire number of supervisors of each type is a management 
decision outside the scope of this document. Prom titc point of 
view of the planner, the important aspect of this determination 
is that each supervisory position must be equipped with a 
console. 

A supervisor of complaint hoard operators will require 
a console equipped like those of the operators, and with the 
capability of displaying the data on any operator console, lie 
may also need to have call director equipment for monitoring 
and patching calls, plus registers to record telephone activity 
rates. 

The dispatch supervisor needs a standard dispatcher 
terminal, with the capability of observing the screens of all 
dispatchers on demand as well as access to all dispatch fr^ 
qucncics, lie may also need auxiliary radio and telephone ter- 
minals for communication with other agencies. Mis console 
wilt have the same capability for creating incident records, 
monitoring incidents, and entering data in the files as the other 
dispatcher consoles. 
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Informntlpn Opomtor 

Mmiy larpm' police ilepartmciits have u Rpeclal poHitIf.n 
tor ill) ini'omtiitioii operator to imiullc siiel) i)oi)'<llsp#tel)inn 
iiiskK UK ipierleK to remote rliitn l?UKeK, rertiiOKlK to umbulimeeti 
or tt)w vehicleK, eomucls with other acpurtincntK, or calls to 
citi/eiiK. Thl'i rethicos the loiul tm the (llspatcher. us thc sini> 
ulatloi) vcKuIlK iniiiciited. 

The Inrormutloi) i)|U’rut)>r requIioK a console similar ton 
dispatcher console, with telephone facilities plus radio termi- 
nals for comimmicallons with other ancncles. 

The inibnnation operator uses a separate channel from 
the dispatchmi; channel; usually one such frequency for the 
information operator Is sufficient for cities ttf up to one mil- 
lion population. 


6.5.3 Types of Dispatcher Personnel 

Dispatchers may be either professional, full-time dis- 
patchers, or field personnel who are assigned to tilts duty in 
rotation with other police duties. I'or a CAD system, some 
moderate degree of typing skill is more Important than tor a 
manual system; typing skills arc on the average not higli among 
field personnel, wlilch tends to slow down tlteir performance 
at a CAD console, Also, the fact that dispatching Is not their 
full-time assignment nor an important aspect of their careers 
makes them tend to be less proficient at the specialized tasks 
of dispatching. Field personnel witlunit good typing skills who 
are brought in for dispatcher assignments generally will lind 
the “type or perish” environment of CAD more stressful than 
the eonvcntiunal mumiul systems. 

For tliese reasons, planners in departments now using 
field personnel for dispatching may wish to review this policy 
in the light of the different requirements of a CAD system 
with respect to dispatching skills. 

If the decision is made to use field personnel, some 
special provisions may be made. One department, in tlie efiort 
tr> reduce to a mlniimim llie amount of typing requited of dis- 
patchers, used consoles will) large numher.s of function keys, 
it is not certain tirat this improved dispatching speed, since 
considerable time would be needed to locate the desired timc- 
llon key among such a large number. 

Having a skilled typist at tlie dispatcher console also 
makes it easier for patrol units to dictate Information to the 
dispatcher, particularly case clearance reports. Officers in one 
department must dictate these reports to a clerk at the end of 
the shift, and may need up to l)alt an hour for this task. 
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Our nbwrvtitloni have not included meaiuremonta of the 
difference! in aeivlco to patrol unita between profeuional 
diapatchera and part-time field poraonnel diapatchera; lubjec- 
tWeiy, our view li that lervlco li better with profeailunal, 
full-time diapatchera. 

5.6 Maiiagemant Report* 

Previous scetlons have Indicated hrlcily tlic kinds of 
munugcnicnt reports that can he generated by a CAD system. 
Although no dcpartmoiit would Install a CAD system simply to 
ptoducc bettor reports, the planner should take full advantage 
of the remarkable capability of a conipntcrlzcd system to gen- 
erate all kinds of reports accurately, rapidly, and at low cost. 

There are in general four kinds of management reports 
tliat a police department needs, and that can he readily pro- 
duced by a CAD system. ’Hre planner’s task is to make certain 
that the required data is available in the computer files, and 
that software is provided with the system to extract the data 
and format the reports. The four categories of management 
reports are; 

• Rouiine statistical reports that are prepared reg- 
ularly for department administration or for trans- 
mittal to state and federal (UCK) criminal statistics 
collecting agencies. Some of these reports may 
include summary analyses such as moving averages 
or comparisons wltli previous periods; such data 
cun be prepared by tlie computer, 

• ActMiy reports tliut typically cover data on patrol 
officer activity, changes in volume or typi* of itid- 
dent for specific parts of the city, response limes 
to citizen calls, and length of time spent on calls 
broken down by area or type of call. Since it 
requires relatively little computer time to prepare 
such logs, it Is possible for department matiageinent 
to have reports more often than would be teasible 
In a tnunuul system. 

• hwklcnt or case iofts are generated bv tiie computer 
at the end of each slilft, and contain most of the 
data nevded for preparation of the others. 

• JMy field activity reports are prepared by Held 
officers and suhinlttcd at the end of their shills. 
Normally DI'AKs are prepared tiiumially, but one 
department (Dallas) hiis a transcriber service In 
wlilch tlic field officer telephones in information 
to a clerk who calls up the appropriate case records 
on tlic display, and adds the officer’s comments 
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uiiil am no oihur writU'ii 

me rPijnlieJ ewepi <or eeriiiin lypes ot Ineitlentd. 
Tills let'lmiipii’ liiis eoiisl»leiHl>lt’ pohsniiiil lor 
le'iIndiiH the piipurwoik load on lit'UI personnel. 

A niiinaKyinent repori treneriiilon tontine ean be piovnied 
to riii|t eliannes or ireiuls tbai eonld Indleiiie problems (ealbniie 
cliiiiiKes in pai'llenlai' beats. sliat'P clninites In ol't'leer poulne- 
tivlty or crime types, etc.), 

Table b Is a list ol'moiitlily reports «enevaled by the San 
Dlerto t'Al) system lor Internal management piirptises. It can 
be seen that these are trrrtanl/.ed in sncli a way as tr> reveal 
trends that may rcriiibv mananemeiit alienllon, I able 7 Isa 
list ol' all the reports rtenerated by the (llondale ( Al) system. 
I'hese are typical of the external and internal reports reriiiired 
for a police department, lixambiatlon ot the list indicates that 
there are some items of data reipdred that are not on the nor- 
mal incident record from the dispatchinn system. Procedures 
must be established to assure that these items of Information 
are entered Into the computcri/A'd files fe.jt,, trattic violation 
records, juvenile case follow-ups). 

Table 8 Is a comparable list for the Dallas CAD system. 
This department has a data section set up spedlically tr) gen- 
erate reports and to analyze the data eollected in the f AD sys- 
tem. The system has on-line primers, permiltiug any rU the 
reports to be generated on demand at any time. 


6,7 Flldi 

The computerl/ed files are the basis for all CAD oper- 
ations, Kiiue it Is the Immediately available and Instantly up- 
riated files that aid the dispatcher In his work, 'lire ahlllty ttf 
the contpniet to search a file and retrieve «»r alter any Infor- 
mation In li within a fracihm of a second provides powerful 
support to the dispuicliing function as well us i<r lire com- 
plaint hoard function, 

As noted hr previous cltiipters, there arc rlegrces ol 
soiddstleallon in CAD systems, and the more sophisticated sys- 
tems use iimre files than the simpler systems. All (‘AD systems, 
however, require a basic set of files dynamically updated by 
the conrpuler, plus a log of all activity. It Is from the activity 
!r>g and Incident files that nearly all of <he management reports 
descrlhed In the preceding section are derived, 

CAD systems tumnally store files oir random access disc 
storage devices, whicli are modular and any number needed cair 
he provided lit the system. Storage capacity is not tisually a 
pmblettr for the system planner or designer. 

Typical files required or optionally included hr CAD sys- 
tems arc listed in l ahle b with the contents of each rccotil in 
the file indicated. 

rhe availability of some of these files may enable the 
police department to render valuable service to the commu- 
nity. f or example, in an emergency the personnel file can be 


Tsbl* 6. Intenul Mansinmenl Raporti Qeneratsd by San Oiago Police Depertment CAD Syitam 





Item Reported 

Breakdown 

Comments 

Calls lor lervlce work load 
tin houri) 

1, Beet 

2. ©tweak 

Ranks beats in descending order; identities beats In 
upper and lower puertile. 

Calli lor lervlce work load 
(In houri) 

1. Time of dev 

2. Dev of week 

Also gives percent ol total men hours spent on 
assignment to calls tor service. 

Number ot dlipeiched callt 
Time spent per cell 
neectlon time 

1, Priority thigh or low) 

2. Boat 

Average end standard deviation. 

Beat work loedi 
Total incidents 
Total work load hours 
On-beat incidents end hours 
Off-beat Incidents end hours 

1. Beet 

Alsu shows percent of Incidents and hours handled 
by beet cur. 

Final disposition ol cells lor 
service 

1. Disposition code 1 14 plus no dlipositlon) 

Also shows total ol all colls lor service. 

Case lug 


Hard copy printout of incident rccorth. 
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CtImR «n(< iMGldini Annlvtli Riporii 

Monthly lummury e( Ineldinti by rtporilnfl dliirlet by day of walk 
Hieip of mejor nctlvlly in ipislflid raporting diitrlfllli) 

Summary ol Ineldanit and/or caia raporti 
Polica activity lummary updata raport 

Juvanlla Activity Raporti 

Juvartitai datninid and dlipoiltloni 

Waakly follow-up report of juvonlla caiai rafarrad to county probation dapartmant 
Quartarly raport of datalned luvanllat raildant by raporting dlitr lot 

Special Raporti for Record Bureau 

Monthly urroit and citation reglitar for BCS* 

Adult mlidamaanor urraiti end dlipoiltloni 

BCS monthly crime and clearance report 

BCS monthly value of property itelan and recovered by offenie 

BCS year-to-date lummary ichedulai of itolen property 

Quarterly follow-up of arreiti pending dlipoiltion 

Preliminary Editing Raporti 
Incident 

Property value update 
Caie iiatui update 
Arreit raport update 
Nonhaiardout traffic violation update 
Team itatui update 



Monthly 

Semimonthly 


Monthly 

Wackly 

Quarterly 


Monthly 

Monthly 

Monthly 

Monthly 

Monthly 

Quarterly 


Oenarel Uie Reporti 
Dally activity log 

Work Stetuiand Employee Evaluation Reporti 
Statui report of eclive cam 
Report of Inveitigativa eiiignmenti 
Empioyae/team/bureeu/iection activity end evaluation report 
Recovered property retained by officer 
Traffic enforcemenr activity (by each employee! 


Weakly 


Monthly 

Monthly 

Weekly 


'Bureau of Criminal Statlitici 


OKMINMI PAOBg 
OF FOOK pOAUni 




TiWi I. CAO-QinfraMit Alpprli - P*Hai PP<i«* 0»|»irtmtnt 


lt«m Rtpoftid 


■rtikdown 


Camminit 


1. Shi 


ioati ranked dv numirer oi cfimei 


Totil crlmei 
Number per dev 
Averege per dey 
Stenderd dewletlon 
30-dey everage 

Reildentlal Burglerlai 
Time, date, day of waak 
Location 

One-word property detcriptlon 

M.O. entry 

Ceie itatui 

Gate number 

Number of luepectt 

Number of vahiclet 

Suipect Perions 


1. Beat 


1. Beat 


Gate number 

□eicription (lex, age, eyei, etc.) 
Weapon 

Vehicle daacriptlon and licenia 

Suipect Vahiclei of Suipacti 
Same ai above 

Suipect Vehiclai for All Grimei In Period 
Vehicle detcriptlon and licanie 


f. Beet 


Ordered by vehicle 


Location of crime 
Data and beat 
Gate number and itetui 

Morning Report of Index Offeniet 
Lett 24 houri 

Month-tO'dete end leit month-to-date 
Lett year month-to-date 
Thli year and I ait year-to-date 


k. aUT'' 

; >.’OUlv 




Accfdont Invest Igutiuns 


Comminli 
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sciiielicil raplUly l« lonate ol'ficcrs with special skills stick as 
illsmamliitH honih Ueviccs or speiiklitd certain I'otclun lanpuases, 

The aJUress I'lle llstetl in lahle n is only one version of 
ftconraphlc files that may he created and maintained. A depart- 
ment may choose to maintain complete records rtf all items of 
interest associated with a given address, such as: 

• Description of the structure, 

• Alarms 

• Indicator of data such as detailed floor plans, maps, 
photos, available on microfiche, 

• Gun registration at the address. 

• Prior incidents at the address. 

• Personnel on parole or probation at the address. 

lliis information can be automatically displayed when 
the address is entered at the console, or can be displayed only 
on request. This is a useful capability, but the creation and 
maintenance of such lilcs involves a targe amount of clerical 
work. 


B.8 Failure and Backup Mcde Operation 

In planning for a new CAD system, a department nnisl 
also plan for carrying on operations in the event ol a lallure 
in the CAD hardware or software. Such plans should include 
detailed procedures for making the transition from lurrmal 
atitomuted operation to manual operation and back again to 
automated operation when the problem has been solved. 

It may he desirable to provide for an intermediate mode 
of operation, in which tire console keyboards and displays arc 
still working, but do not access the computer files. In this 
mode the complaint board operators can still use their key- 
boards to enter incident data, and can then cause it to be 
printed out on the printers at the dispatcher consoles. 

Fhe transition procedures can be exercised on tlie 
occasion of routine maintenance procedures or shifting of the 
computer to perform periodic batclr processing of the data 
base (as in preparing management reports). It may also be 
advisable to hold unscheduled “fire drills” to verify the tran- 
sition procedures, Supervisors normally play an active role in 
coordinating the transitions. 

Detailed procedures and their effects on hardware and 
software are presented in Chapter 6. 
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Determinet whether or not addreit 
fllvon by cotnplalnont SKltti. 

Locates acldrett by crou streett, beat, 
and reporting diitrlcl. 

Reports finding to operator, 


Conveys Information from t '■leinun 
to dispatcher. 

Conveys information from dispatcher 
to patrol officer. 

Summary for case log and data base 
for management reports. 

Reaction time and delays. 


Street name. 

Number range. 

Number range of each block face. 

Name of street ut each iittersectlon. 

Beat. 

Reporting district. 

Name of complainant, his address and phone 
number. 

Type of incident. 

Priority. 

Officers and cars assigned. 

Time and date initiated, assigned and disposed of. 
Time and status changes for each vehicle in case. 
Incident number. 

Precinct number, beat number, reporting district. 
Operator receiving cell position. 

Dispatcher assigning call and position. 

Frequency. 

Silent alarm number. 

Disposition. 


Vehicle Status 


Display resources to dispatcher and 
their availability. 

Display case numbers end vehicles 
currently assigned. 


Unit number. 

Terminal number. 

Number of personnel in car. 

Beat assignment. 

Temporary assignment. 

Radio channel. 

Shift. 

Time assigned on shift. 

Updated by operator number and time. 

PIN numbers of officers assigned to vehicle. 
Status. 

Time-entered status. 

Incident number. 

Type of incident. 

Priority, 

Number of unit covered or boing covered, 
Status chenges timet and case numbers for that 
shift. 

Comment. 


Incident Summery 


Provides 1-line summary of inci- 
dents assigned but not yet cleared. 
Provides 1-line summary of Inci- 
rJents in backlog to be assigned. 


Incident number. 

Start time. 

Priority. 

Time received. 

Typo. 

Location. 

Number of assigned unit. 
Frertuency, dispatcher. 


ioojj QVAinY 
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FMt Ntrn* 


Dapartinunt Pertonnel 


Department Vehicles 


Table 9 (Continued! 


Function* 


Content 

Hotter of iworn end non-imorn 

1. 

Name. 

staff. 

2. 

Rank, 


3. 

D.O.B. 


4. 

Date joined P.D. 


6. 

Home address. 


6 . 

Phone number. 


7. 

Next of kin, address, phone number. 


8. 

PIN number. 


d. 

SS number. 


10. 

Special capabilities. 


11. 

Blood type. 

Inventory of petrol vehicles; shows 

1. 

Vehicle number. 

special equipment on each (com- 

2 . 

Model, year. 

munications, mobile lab, etc.) whether 

3. 

Communications, e.g., types. 

or not they are in shop, time to bring 

4. 

Lab equipment. 

out of shop. 

B. 

Other features (ambulance, tructor, van, 
bus, etc.). 


6 . 

In shop for repair of 

part 


7. 

Estimated return to active status 


dele, time 



6 . 


PLANNING GUIDELINES: ELEMENT? OF THE SYSTEM 


We Imvc seen In ('Impter .1 liow it C'AI) system works in 
(tcncriili iiiul wliiil its comiuments urc. litis diapter provides 
more detailed iiil'oimaiion on tltose components, Section ft. I 
describes the hardware elements of tiie system, and Section ft.2 
covers the computer prttgrams and cmnputerl/.cd files tlmt 
are needed for a (’Al) system. 

liefore wo describe the cmiipononis of the system, liow* 
ever, it will be useful to present an overall picture of tlie physi- 
cal layout of a command and control center with computer- 
aided dispatch. I'igure 10 is a drawing of a typical center. 
Some of the points to be noted iierc tiiat have not been 
mentioned previously arc: 

• The computer and its related equipment (tape and 
disc units and interface devices) do not occupy 
much physical space; the equipment generally does 
not require specially conditioned facility space. 

• There is a position, with a separate console, for 
a watcli commander. The watch commander is in 
overall charge of the center and of the patrol 
units. His console enables him to observe the 
screens of any of the other consoles, and his 
radio panel permits him to communicate with 


p.itro| units on any of the frequencies being used 
by the dispatchers, lie provides overall monitoring 
of the entire operation c. well us high-level deci- 
sion making for emergency or tmusual sittiutions. 

• There is a position for a records clerk. This posi- 
tion has a cotisole with a display screen, but has 
no radio panel and does not communicate with 
patrol units. Its function is to handle all off-line 
functions such as preparing personnel rosters, 
updating the permanent files, transferring logs 
from disc to tape for permanent storage, genera- 
ting computerized management reports, etc. 

• Tlierc is a spare console for training. This is identi- 
cal to a dispatcher console, and can be used as an 
active console to handle overflow loads or in case 
of failure of an active console. Its nominal pur- 
pose is to provide practice for new operators. 

• A microfiche file is available to the dispatchers. 
This is a means of storing permanent reference in- 
formation tliat the dispatchers may need occa- 
sionally for tactical situations. This microtiche 
file is equipped witli a system for rapidly retriev- 


CARD READER 
TAPE READ /PUNCH 



Fig, 10. A CAD dlipatch centtr 
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(a) WOHIt POSITION 


Linusi 2*S are used fur detailed inform at iuti fill- 
in by the operator and beeoinc part of the 
permanent computer record, which is auio- 
malicully transmitted to and displayed on the 
dispatcher’s incident CRT. Lines 6-9 and lO-l 3 
are duplicate complaint entry formats. Lines 
14-24 indicate the complaints, in order 
received, entered Into the system. This Infornia 
tion is duplicated at the dispatcher’s incident 
CRT. 


(b) COMPtAINt tNtSV D1SPUV 


Fig, It, Complaint 



optraior nation 





omectoi 




(a) WOlIK POSiriON 

Photo courttiy of Lai Vagat Metro Poliea Department. 


Stilus Diipliy 

Cor numbers (corresponding to car types) are 
displayed under appropriate headings of AVAIL- 
ABLE. ENROUTE, AT SKENE. INVESIl- 
GATING, RETURNING TO SI ATION, OUT. 
This information is entered directly from the 
vehicle via the MODAT mobile data system, 
Where applicable, the case number to which a 
vehicle has been assigned is displayed next to 
the vehicle, t'he upper right-hand corner dis- 
plays the backlog of unassIgned Incidents per 
beat. Line 2 shows unit 3A2 requesting a car 
slop check. Line 3 Indicdles that 314 lias not 
been assigned to a mobile unit in the computer 
files. Line 4 indicates which mobile units arc 
transmitting emergency messages. Line S shows 
other cars transmitting messages. Line 6 is tiie 
automatic ID number which appears whenever 
a mobile unit uses voice-radio. 


Dispatcher Incident Display 
A computer-assigned Incident number appears 
on Line 2 as well as time received, nearest street 
(if applicable), Apt. No., reporting district, I- ire 
Box No., and Beal No. Lines 3-5 indicate the 
name and phone number of the person report- 
ing the incident, the unlt(s) assigned to the inci- 
dent, and the type, code, priority code, and 
description of the Incident. Lines 10-12 indi- 
cate assigned but unresolved incidents, willi liie 
incident code on Line 9. The bottom pirrlion of 
the screen displays an abbreviated version of 
the top portion of the screen: unassigned inci- 
dents, type code, lime received, address, inter- 
sect street, reporting district. 


(h) OISnAYS 



Pig. 12, Oiipatchar atatlon 






lug any of the atorod data and u^nlaylng it on a 
mlcrotlcho icreon, e.g„ street maps, layout of 
premises such as hanks, etc, 

llie physical arrangement of the equipment is quite flex* 
Ible. In some cases the complaint board operators are In a 
different room or a partitioncd*off part of the room from 
the dispatchers, Tlie computer can be in a different room if 
it is more convenient, and the records clerk cun also be in a 
different locution as long as he has a connection to the 

computer, 

For the purpose of filling in a picture of the physical 
appearance of a CAD system. Figures 1 1 and 12 show, respec- 
tively, a CBO console and a dispatcher console, with typical 
displays on the screens. Note that in both types of consoles 
there is a provision for cards so that in the event of a failure 
in the CAD system the CBO and dispatcher can continue 
their functions in a manual mode. 


6.1 Hardwire DMcrlption 

Tills section idcntlflei the types of equipment, needed 
in a CAD command and control center, it takes a particular 
example of such a center and describes in some detail the 
characteristics of each item of equipment; the center Is slaed 
to serve a city of approximately one million population, 

The equipment layout of the center we will use as an 
example is shown in Figure 13, It consists of the communica- 
tions equipment, the computers and related peripherals, and 
the set of consoles where the functions of the center are 
performed. As the figure indicates, the consoles assumed in 
this center are as follows: 

• F.iglit CBO positions (four dual consoles). 

• One complaint supervisor position. 



voict 

rig. 13. CAD lyMtm btock dltram 
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• I'mir (littpuU’liei imsItiouK (two duul (foiiNolcs). 

• One diKpulcIi hiipeiviMii piisillnn, 

• Two commmul poKltioiis (one duul console). 

• One service iitul triiliiiiiH console (two positions). 

The ilispatcli supervisor, connnaiul. iimi set vice and train- 
iiiM consoles are essentially Identical to llie dispatclier consoles 


and are aide to operate as dispatcher consoles whenever re- 
(|iiired hecaiise ol' overilow work load or lailure ol a reKiilar 
dispatcher console. 

The cliaracterlslies of tlie consoles are suinniari/ed in 
I'able 10. In the system used here as an example, the command 
console is used to monitor operations, provirle necessary input 
or feedhack, and provide a chamiel for command decisions 
In cases requiring them. The service and training console is 
used to mouilor tlic records channel, serve as a training posl- 


Tibit 10. Summary of Conioli Charaotarlitloi 


Potition 

Componanti 

Function 

Complolnt board oparotor 

Keyboard 

Enters Incident date to computer. 


CRT display Islngle) 

Displays format and data as It It entared. 


Call director 

Accepts calls from public via multitrunk telephone Unas. 


Instettt playbeck recurdar 

Captures Incoming call for quick retrieval of Information If 
necessary to confirm or check data. 


MIcroficha flies 

(one set for two positions) 

Provides maps and other data such at legal Information, other 
agency referrals. 



Provides for manual taking of complaints if CAD system It 
not functioning 

Comptaint board tuparvitor 

Same as CBO, plus: 



Cell director supervision 
equipment 

Monitors Incoming cull handling. 


Telephone activity registers 

Provide historical records of telephone activity. 

Diipatcher 

Dual CRT display 

Displays all formats and date. 


Keyboard 

Enters data to computer. 


Instant playback recorder 

Captures voice messages for recheck. 


Microfiche flies 

(one set for two positions) 

Provides street files and maps, other static reference 
Information. 


Radio dispatch panel 

Provides radio communications with petrol units. 


Manual equipment 

Permits manual dispatch If CAD system Is nut functioning. 


Printer Iona for two positions) 

Provides printed records ei needed. 

Dispatch supervisor 

Seme as dispatcher console, 
except: 



No menuel equipment 



Auxiliary radio panel 

Provides fur cummuniceticn with other agencies. 

Commartd coitsole 

Same as dispatcher console 
except: 



No Instant playbeck recorder 



Au..'llary radio panel 

Provides tor cummunicetion with other agencies. 
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tion for new opcruiorii, uiul ImnUle tow iiml umluilMnee 6.2 SOFTWARE AND FILES 
(lisputclies. 

The lemi “softwiirc" Is used (o refer lo llie set of Insirue' 
As shown In I'ijture 1.^, this system used as an example iU)ns exeeuted l>y the eompnter lo perform Its tasks, phis the 

has two processors. They are eompletelv redundant, with ilaia In maehlneueadahle form that is used hy the computer In 

either hcintt capahlc of handlittfi all tlie eomptitlnit reritilrcd earryinp out these tasks. The Irasic Instructions ennhiintt a 

for tltc CAD system (hut note that tlie nuiltiplexer switch neueral-purpose computer to accept specific pronrams are pro- 

provides for future additions of processors to handle other vided hy the computer manufacturer; these basic instructions 

automated command and control functions), 'fable 1 1 sum- are usually referred to as the operatinjt system. The specific 

mari/es the hardware characteristics of the processors and programs that cause the.computer to perform particular tasks 

their peripheral ei|Uipment. are called user programs; some wldety-used programs (such as a 

payroll program or an inventory control program) may be sup- 
No description is provided of the communications ccpiip- plied by a computer manufacturer or by an independent soft- 

ment shown in Figure 13, since It is standard ei|Uipment used ware house. 'I'he files of data are naturally always provided hy 

for all law enforcement command and control systems. the user himself, although the file struclure may lie a slandard 

whether or not they have a CAD system. one. 


T*bt« 11. Summary o1 Computar Hardwara 

liam DaMrIptlon and Function 

Proceuort Each coniitu of a central proceiilny unit (CPU), memory (uiually magnetic corei), and input/ 

output logic. The memoiv itorei program Instructions and data: the CPU executes the 
Instructions, using the stored data; the I/O logic Interfaces the processor with the input devices 
tthe console keyboards, the disk end tape units) and the output devices Ithe console displays, 
the disc and tape units, pi inters) to move data into and out of the processor. 

Disc storage units There are one or more disc units in the system, depending on the site of the flies to be stored. 

Ordlnarity a single disc pack with a capacity of several million bytes Is large enough to store all 
the programs and date for a CAD system. Disc storage provides a means of rapidly accessing a 
lerge quantity of data or Instructions; those programs end files that are not maintained In the 
processor's core memory are stored In the disc unit, where they can be brought Into core as 
needed in a matter of milliseconds. Duplicate disc units with duplicate date are sometimes main- 
tained to protect against accidental data loss or disc syitem failure. 

Magnetic tape units Tapes are normally used for permanent storage of data, and the amount of date that can be 

stored in this way Is virtually unlimited. Tapes are usually easily transferred from one facility to 
another if they are needed for historlcel or statistical studies. 

Card reader The normal method of entering programs Into the computer for Initial development anu checkout 

li through punched cords. A 300-cerd-per-mlnute reader should be adequate fur o CAD system. 

Line printer Any printed output from the system that has significant volume, such as activity logs and oil 

types of menegemam reports, requires the speed of a line printer. The printer would normally 
be associated with the records clerk position. It need not be a very high-speed printer, bot 
should be faster than a leteiypewrlter. 

Console teletypewriter A teletypewriter is provided for each pair of dispatcher positions (one per duol console). This 

fahly low speed printer is adequate fur generating the small amount of hard copy needed from 
the consoles. 

Modems A modem (modulator/demoduletor) Is needed for each interface of the CAD system with other 

digital systems, primarily lor purposes of remote data base query (OMV, NCIC, etc.). A modem 
allows a computer to communicate with another computer over standard telephone lines. A 
modem Is also needed In systems where the patrol units ere equipped with mobile digital termin- 
als that can communicate directly with the computer or with remote data bases. 
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j•llr » CAU NysiPm, we Bssume ihHt the sotiwtire will he 
supplied uloiig with the rest ol' the system hy u etuttrueitu, lie 
will itormidly hiiy the computetK lofiether with the operulltitt 
syKtems Kol'twitre, hut inittht modify the operutinit Kysiem Kome* 
whut to meet the puriieiiltir retpilremeittK of the CAD sysicm. 
The tiser prnunims would he providetl hy the CAD system eon- 
irtiutor. In cities where there Is a lai>te and experienced data- 
processing ilcparimeni, it Is possible that the city would act as 
its own contractor and procure the hardware (Including operat' 
Ing system) and write the user programs in the data processing 
dei^urtment. liven where the complete system Is procured I'roiu 
a contractor, city ttr police department programmers may 
take care of software maintenance. Malmcitance usually refers 
to making modifications in the programs to tailor tliem speci- 
fically to the conditions of operation, or adding extra capabil- 
ities that iotprove the overall CAD operation. 


I'lgure 14 shows the slrucutrc of the software and files 
that would be needed in a CAD system. Ihere is a basic set of 
software that would be needed for any CAD capability; this Is 


Indicated hy an asterisk. The remaining elements of soitwaie or 
files are optional added capahilities. 

The following sidrseelionsdescrihe the software elements 
listed in Tahle 1 2. The planner may limi these useful in that 
they give a clear hlea of what each part of the sol'tware is re- 
<|uired to do. With this understanding it is easier lo evaluate 
proposals from syriem or sol'tware vendors. 

6.2,1 Operating Syitem 

It has already heeii mentioned that (lie operating system 
is normally supplied hy (he computer mamifucturer, since its 
detailed stmeuire is heavily iiitliicnced hy the design of the 
eompulcr amt the peripheials furnislied witli it. The separate 
parts of the operating system are hrielly descilhed helow. 

Systm (h'lwmiifin A/m/mc, This is the set ol procedures 
and instructions tliat defines tlic operating Kysiem, the system 







OMRATINCn 

SYSTEM J 

[ USERS 
1 PROGRAMS 


DATA 





REAl-IIME 

FIITS 

permanent 

HlfS 

‘ SYSTEM 
GENERATION 

• SION-ON/ 
SIGN-OFF 



• J08 

SCMEDUUR 

* incident 
LOG-IN 


• ACCESS 

au!hoRI?ation 

ADDRESS 

VERIFICATION 
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REAU TIMBPH.es 


RMtni Slit 
(•Mntttnl 


Agmh lulhurliitlon 
Ineldtni flit 
Inslrttnt lummtry flit 
Piirol unit italui flit 
Ridlo-tilitphont ilitlitici 
Opiritor acilvlty flit 
Patrol unit activity flit 
Otploymant Kitadula 
Ttmportry iliuttlon flit 

PtRMANENT PILES 

Addreii varlfloatlon 
Siraat InPax 
Landmark lilt 
Maittr itraat flit 

Taltphona dlractory 
Emargancy talaphonei 
Poraign langutga t.anilatlon aiilitanca 
Nonamargancy talaphonai 

Addreii intalllganca flla 


66 par ptrwn 
660 par Inoldtitt 
63 par incidani 
170 par field unit 
100 par hour 
603 par operator par ihift 
920 par unit par ihift 
124 par ptrion 
1 76 par addraH/araa 


230 par itraat name 
06 par land mark 
02 par block fMa 

80 par talaphona 
BO par talaphona 
80 par talaphona 

246 par addrtit/araa 


coiiflguratiun (i.e., what procensors and peripherals are parts 
of tite system), the mode of operation, the disc file catalog 
identifying programs and file locations, and tlie software rou- 
tines that are to be maintaineu in the core memory. 

Job Scheduler Afodute. Control over the execution of all 
piograin elements Is exercised by this module. It maintains a 
priority job queue and executes the higli-priorlty jobs In the 
foreground with the lower.priorlty jobs being handled in the 
background (the background means the Intervals of processor 
time nut being occupied by foreground jobs; these intervals 
are generally on the order of milliseconds or less). There Is also 
a priority Interrupt feature allowing a high priority task to 
take over the processor when It enters the queue. The function 
of the job scheduler is to schedule and coordinate all the avail- 
able processor execution time in accordance with the hierarchy 
of priorities. 


CofwWMMit’flffoMi Control Mode. This module provides 
for testing of Input data for syntax errors, for message handling 
in accordance with a given protocol, and for system-level oper- 
ators to Interact with the system as needed during Initial sys- 
tem generation and later maintenance, Die updating, and pro- 
gram development opeiatlons. 

Executive Services. This is a set of routines that support 
user programs in handling data. For a CAD system they would 
Include the special input/output handlers to drive the CRT dis- 
plays. to sort, edit, and route the input keyboard messages, 
and to enter data in the designated portion of the display. This 
module also includes the timer routine that activates time- 
related tasks for execution, and various utility programs to 
handle transfers from disc to core or vice versa, or from disc 
or core to printer. Other utility programs Include software 
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utiU uNsPiiiht^rR, foiitiii0K for nnrf iijHititing 

dlKt,' 

Hccomy. Tliiti module juovIdeK lor Hutomutk 
miiixl'er of Kyiitem operntliui to u rcdmiduiit tiliive prouoNKor 
(If <me Is Insiulled) wlieucvcr the muster processor error detec- 
tion romlne senses it fiiflure, or witonever the sluve processor 
detects the loss of mnster-sliivecomimmlcutlons. In either case 
the processor thut rcnmlns opcrutioniil Immcdliitely gcneriites 
messuges to selected tcrmlnuls and prints out a failure message 
on the console mainteiumee teletypewriter. 

8.2.2 liter Progremi 

Si((H-()n/Sinn-Off. All operator.s and field personnel 
scheduled for active duty are required to sign on and sign off 
the system, lids enables the system to maintain a current file 
of all personnel on active duty, The sign-on piuccdure requires 
the C'BU and dispatcher to input his personal ID code; the 
processor tlicit makes a cursory security check of his ellglbi'ity 
to operate the system and of ids authorl/ation to access speci- 
fied data files (for example, a (TK) may not be allowed to 
change patrol uidl status or supervisory data or to modify the 
address intelligence file). 

Unce the dispatchers and CTiOs have signed on, the dis- 
patchers (or other operators) will sign on the personnel iit the 
partol units under their respective control (unless they can sign 
on directly through their mobile digital terminals). When the 
sign-on procedure has been completed, the program will gen- 
erate a test pattern on the screen to indicate that the procedure 
is satisfactory, and will also display all pending transactions so 
that the dispatcher can carry on without interruption from 
the previous shift. 

Lach individual person who signs on will have his own 
activity file in the system, where all transactions executed from 
his terminal will be logged. 

Wlien the person signs off, this procedure causes his acti- 
vity file to be closcci and printed out (mi demand). Ills ID is 
removed from the file of people on active duty, and the apprm 
priulc supervisory tenninal is notified of his sign-off. 

Itii'hU'iit /.fg 7 h. riie incident log-in routine is executed 
whenever a new incident record is to be created. It is used 
mainly by the ('BOs, but when an Incident is reported by a 
partol unit, the dispatcher makes use of this routine to enter 
the incident into the system. Mils is an Important and 
frequently-used routine, consisting of the following steps. 

When the operator types INC and presses the I NTliR 
key (or presses a special function INC key), the routine dis- 


plays the hteideitl roeord lormal on the sctepti, as sintwit iit 
rigttre 11. The program automallcally enters data itt the cot 
reel field and displays It on the screen as etttered. l or exattiple. 
to enter an aihlress the operator simjily types the liehl identi- 
fier ((‘A Itt this case) followed hy a nIukIi (/) and the data. 
Names, incident type, etc., catt he etttered In similar fashiott. 
The advantage of this piocedtirc Is that the Inlormution ctm he 
entered In any order. 


Wlieii all the avuiiahle data has been obtained from the 
caller, the operator depresses the llNTliK key and the infor- 
mation Is transmitted to the proeessor. Tlterc It is scheduled 
for execution hy the part of the executive service routine tiutt 
asscmhlcs the data, places all entries itt the proper field for the 
dispatcher’s display, and hands it over to the incident log-in 
routine for serial mmilicring, time-tagging, and address check- 
ing (if the system has such u feature). I'art of tlie address check 
is having the master street Die searched to see if previous inci- 
dents have been logged in tlic same block. If tiiere are sucli 
incidents, all of them are displayed on the CBO screen along 
witli the current incident to allow for veritlcution that the new 
Incident is not a duplicate of a previous one. If it is a dupllcule, 
the new incident Is cancelled. If it is the same as an existing 
incident but with new data, the original incident is updated and 
transferred to the dispatcher for action (which may lie to can- 
cel it). New incident entries will cause a Hag to he set in the 
master street file to indicate a pending incident in tliat block 
and the ilag will be removed wlicn the incident is closed. 


Tlie next check made by the incident log-in routine is 
again against the address, but this time against the address 
I'lielligencc file (If this feature Is included in the system). Any 
information found In the file will be displayed with a special 
caution marker if the intelligence data contains a caution i1ag; 
tliis is to help the dispatcher make his dcdsiotis and to increase 
officer safety. 

One of the fields filled by tbe CBO is iniddeiit priority. 
The priority may be I, 2, or ^ (1 for immediate action). Tlie 
log-iti routine automatically notifies tlie tactical dispalchot 
console (or other dcsigtiafed supervisor) whenever there is a 
priority I Incident. 

I■lnally, if tlie system has the dispatch recommendation 
feature, the log-in ronline cliecks the patrol iniit status tile 
against the muster street file to identify tliose units that are 
iiea.'cst the incident and available, and displays tiie list ot such 
units to the dispatcher, This iiiformalion is added just us tlie 
incident log-in routine hands the incident data to the dispatch 
log-in routine. 
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Plspawh l.og‘ln. TIus routine reueiven the liielileiu dut» 
rroni the Incident In^dn routine uiul (llspliiyft it on the itlN> 
patcher console wlien he culls it up in its turn, t'igure 1 2 shows 
the format of the display presented to the dlsputcher, The 
dispatcher now decides whether to assign a patrol unit or to 
defer dispatching until u later time. If he decides to dispatch, 
he selects u patrol unit or units from his patrol unit status 
display (or from the list of rcconunendutions presented by 
the computer, if his system has this feature), lie types in the 
ID's of the unit or units selected, and notifies them. As soon 
us he receives an acknowledgement of the assignment, the 
dispatcher presses his ENTIiR key and the computer time 
tugs the assignment and updates the status display. An 
incidcnt/dlspatch summary task in the dispatch log-in routine 
takes all the incidents processed by the dispatcher (assigned 
or deferred) and generates a summary in the format shown 
in Figure 1 2. When the dlspatdrer wishes to recall the full data 
in in incident listed in the summary, he types in the incident 
serial number and depresses liis ENTER key. The incident 
summary table is printed out at frequent intervuis on the 
printer at the console, to provide data in case it is needed for 
manual backup operation. 

Wlien an incident is to be closed, the dispatcher enters 
DC/CLOSED plus any data supplied by the patrol unit to the. 
Incident display after he recalls it. The processor confirms the 
action by showing the time of log-off: the field unit status dis- 
play is automatically updated, us before. 

Patro< Unit Status Routine. This routine maintains the 
status file for the patrol units assigned to each dispatcher. The 
format is shown in Figure 12, with the available units listed 
on the left side and busy units on the riglit side. The available 


units are listed by number and heat. Backup units supporting 
the primary unit arc listed Immediately after the primary unit 
regardless of number or area, and show the same Incident num- 
her as the primary unit. 

The routine automatically shifts units from one column 
to the other In accordance with dlsputcher inputs (or direct 
Inputs If the patrol units report status digitally). The time col- 
umn shows the time the unit made its last status change. If 
there is a limit on the time u status code ^lould remain un- 
changed, the processor will cause the time signal to be flashed 
to alert the dispatcher. Time limits may be automatic for 
certain status types. 

The patrol unit status routine transfers to the activity 
file for each patrol unit each status change entered for that 
unit. When an entry indicates that the unit has logged off, the 
activity file is closed and scheduled for tape lugging and print- 
ing (on demand). 

A special task in the patrol unit status routine is used 
to update the files during recovery after a period of manual 
operation. It accepts inputs from the keyboard and updates 
the files and displays. Tltis task also prints out the status files 
on the console printer periodically, say every 10 minutes, to 
provide a starting point for manual backup operation if it 
should become necessary. 

Data Base Query Routine. This is the routine that 
allows dispatchers to initiate queries to remote data bases at 
the regional, state, and federal levels. The routine formats the 
query and response data, maintains a record of the transac- 
tions and prints out the query and response for "hits’*. A 
typical data base query format Is shown in Figure 1 5. 


lUU) - NAMM HU K l>HN I tA'. Ill MA'. IlMl IMH Ui 

MM IIIIIN '.MUM HA Wlini '.V M l)H I 1 /■' 

',A I'./ ,>Nlt HOAD III Mn'WM'.(l HH III K I'.HKN 

I A ( A _ Mf, /V 14(> Dll- 1AUM.I 

MM MAliV lOMI D' 4; -A l'> I lA 
Ml'. -NMKMAMI IAV 

I Ml I ^ (lI\-NitWANI '.lAM MIUVAMI Mill A^IIIMKII 
I Al' V 1,M 

iw I Mil iniAA '.Mini iiiMM II M w ivniinr. 
iK.rMM wi.i'iMi MAi'tni. v'.ir'.i ii mnd 

mmm'A'. o'.m'./a') '.01 'maD'Hi, um'iawa'.i i am. 

OM1A dmwdah/a (KA'.ohm mm 'W iiomAy/iA 

Ml'. '.Mil IDAI MMMI-MI ir. WAMMM lOH MimillU will 
IMMI IMAM I OMI HIM WAIIIIAMI AND I VMIADIIIOM WIIM Mill 


Pig. 16. Typical data biM qutry format 
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KeNpoiiHtf nii'iisu^C!) urc scrpt-'iuid loi' po«i|ilv« c;tiitiomiry 
chiinicUTK rvt;clvcil us piirl of the I'csponse. IXMc’dioii of u 
ciiuiion diiiriicler will ervatc a hlgh'prlorily retipoiuc, cuiitdiif; 
tite console that ctitcrcil ilic (piery as well as the sapci visoiy 
console to he notified immediately. Positive responses arc 
also printed out on n special printer. 

Mamgmeiit H- porting, A separate routine is provided 
to collect from the log tapes the necessary data to (icncratc 
the set of manaitcmcnt reports selected hy the department 
management. Some typical management reports arc listed in 
Section .S.O, 

Data Logging Routine. Thi.s routine handles the tasks of 
formatting all the data in the real-time files for pcrmnneni 
storage on magnetic tape, it maintains accountability of all 
messages into and out of the command and control center and 
transactions within it. 

6.2.3 Data Filet 

Figure 14 identitled two types of files; real-time files 
and permanent files. The real-time files arc those used by the 
CAD system in its basic functions, and their contents change 
rapidly all the time the system is operating. The permanent 
files are those used primarily for reference; they arc not com- 
pletely fixed, but they are updated at relatively long intervals 
(once a day to once a month) compared to the real-time 
files. 


The contents of the files identified in the figure were 
listed in Table 9 together with their functions. Table 12 lists 
the files again, showing the approximate number of characters 
that could be expected in each record in the file. 


6.3 Sizing the System 


Determining the quantities of hardware components and 
their individual capacities is normally done during the detailed 
system design. Nevertheless It is useful for the planner to know 
how sizing estimates are made; this section describes a proce- 
dure for doing so, based on the needs of a city of one million 
populaliun. 

6.3.1 System Paramotari 

Those parameters readily available to the planner from 
the existing police command and control system are: 

• Average number of calls fur service in peak h. 'trs. 

• Maximum number of patrol units deployed per 
shift. 


From these numbers he can derive some numerical ('Al> 
requirements by using some rules of thumb that have proved 
generally applicable to cities in the 500 thousand to one mil> 
lion population range. These are listed in Table 1.1. In addition, 
approximately 40 percent of culls for service generally result 
in dispatches of patrol units. 


Tabla 13. Eiiimating Riifos for CAD Syiltmi 


Pirimctcr 

Number per 
Patrol Unit 

Sslf-diipatchet (patrol unit originated) 

4 per shift 

Data bate queries 

2 per hour 

Data base query responses I2.S responses per query) 

S per hour 

Partol unit status updates 

toper hour 

Miscelleneous supervisory transactions 

2 per hour 


11ic final parameters needed fur system sizing relate to 
system performance; fur a CAD system these are primarily in 
the form of required response times. A typical set of require- 
ments is listed in Table 14. 


Tsbit 14. Typical CAD Rctponio Time Rcqulrcmcntt 


Oparetlon 

Maximum Time to Perform 
Opirction 9BS of the Time 

Answer call for service 
CAD system procetsino of Incident log-in 
Update patrol unit stetus/locatlon 
Display of data maintained In CAD files* 

10 seconds (first ring) 
2 seconds 

1 second 

2 seconds 

*Time does not Include operator typi-ln time. 


Once these parameters and response time requirements 
have been established, the sizing process proceeds in the follow- 
ing steps: 


(1) Determine number of work positions ((’HO. dis- 
patcher, supervisory, others if any). 
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TranMOtlgn Typi 

Number 

Per (TImafI Number 

Units 

(Bquelsi 

Transeetlons 
Per Hour 

DlipatchAl 





1 

1 

1 

130 

From call! 

0.4 

call 

200 

calls 

1 

(80) 

From Mif 

O.B 

PU* 

100 

PUs 

1 

1 

(60) 

Diipatch loe-oft 

1.0 

Incident 

130 

Incidents 

1 

1 

130 

Data base pueriai 

2 

PU 

100 

PUs 

1 

1 

200 

Data base reiponiet 

2.6 

query 

200 

queries 

1 

1 

BOO 

PU atatut updates 

10 

PU 

100 

PUs 

1 

1 

1 

1000 

Miscellaneous luperultorv 
massages 

2 

PU 

too 

PUs 

1 

1 

1 

200 

Hard copy print 





1 

1 


Diipatcher records 

6 

dispetcher 

4 

dispatchers 

1 

1 

(24) 69 

Data base query ’’hits" 

0.16 

query 

200 

queries 

1 

1 

(30) 

Management records 

6 

total 



1 

1 

(6) 

Telephone-radio statistics 

1 

total 



1 

-t 

1 

Total transactions (per hou 

j 2220 

r) 

•PU - patrol -init 


(2) Delcrmiiie total system input/ouiput transaction 
rate. 

(3) Determine required CPU capability to handle trans- 
action rate. 

(4) Dciermlne core storage requirements. 

(5) Determine disc storage requirements. 


These steps are outlined in the Ibllowing sections, using as an 
example the CAD system described in Sections 6.1 and 6.2. 
For that system, the curves shown in Chapter 5 indicate a 
requirement for K CIK) stations and 4 dispatcher stations, plus 
4 addilionai stations for supervisory and maintenance func- 
tions; the additional stations are defined to meet the needs 
of a particular system atid are not derived trom the curves of 
Chapter 5. 


6.3.2 I nput/Output Transaction Rate 

To determine the total I/O transaction rate we Identify 
the types of transactions and estimate the numbers of each 
from our pcrviously established system parameters. This proc- 
ess Is shown in Table 1 5 . 

The number of operations per hour required of the sys- 
tem can now be estimated. We assume the following numbers 
of operations for each transaction: 

2 keyboard messages 
2 screen displays 

1 magnetic tape log record generation 

.S operations per transaction X 2220 transactions = 

! 1 ,100 input/output operations per hour 

Hiis translates to .324.3 milliseconds per operation. 


1 

1 

5 


i 

j 
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Now, uiiikiiitt Nome coiiservutivc UNNumptlons iibmir vycle I'or the syNtcin outlined in Sections (\. I imd (\. 2 , ihc core 

lime and allocation of time to opeiutlons (averaged over un storage rc(|iiirciiicnts can he estimated as Tollows: 
houi*): 


Program execution time 
Three disc access 
Data transfer I/O 

Interface multiplexer to con* 
sole transfer of l‘MO bytes 
(two times) 


6 

120 

3.7 

3«.« 


168.5 milliseconds 


Real lime operating system 

16K 

CAD user programs 

I6K 

Input buffers* 

12K 

Output buffers* 

9K 

'Total 

S3K 


we sec that the system assumed cun handle approximately two 
times the estimated average peak load (i.e., it requires only 
168.5 milliseconds to perform tasks for which 324.3 millisec- 
onds are available under the assumed loud conditions). This is 
still a very conservative estimate, however, since of the 168.5 
milliseconds shown above, only 6 milliseconds are used by the 
CPU**; the rest is for data transfers. Thus the CPU can be 
performing other tasks in parallel, as long as they do nut 
involve the same peripherals (CRTs, keyboards, printers, etc.). 
It may be possible to trade off the extra capacity for lower 
cost hardware witli less capability, or to keep it available for 
future expansion of the system to accommodate new capabili- 
ties such as mobile digital communications. 


The above calculations assumed a typical 1 6-bit minicom- 
puter with an average instruction execution time of 3 micro- 
seconds or less, having direct multiple access (DMA) channels 
to interface with the consoles and peripheral equipment. 

6.3.3 Core Storage Requirements 

The core memory :n a computer is used to store the 
operating system software required during real-time operation, 
the CAD specialized process control user programs, and buffer 
storage to handle data transfers to and from the consoles and 
the peripheral devices. 'Typical minicomputers of the type used 
for CAD applications are available with core storage modules 
of 4, 8, and 16K words (each word of 16 bits), generally up to 
a total of 65K words of directly addressable core storage 
locations. 


*The calculations shown arc for operator terminal I/O coimnunica- 
tiuns which constitute tlie majority of transaetiuns anil take the 
longest transfer times from CPU to terminal. 

♦♦Central Processing Unit. 


6.3.4 Disc Storage Requirements 

Random access storage other than that provided in core 
is usually provided by disc storage devices. The categories of 
data to be stored on disc arc listed in 'fable 16, with estimates 
of the number of bytes (1 byte = 8 bits) of storage required for 
each category. These estimates are derived from simple calcu- 
lations based on the previously established system parameters 
and performance requirements. Note that some of the types 
of data included in the estimate arc fur optional files, as 
defined in Section 6.2, and tliat the total can be decreased by 
these amounts if the optional files arc nut included in the sys- 
tem design. 


6.3.5 Siting Summary 

The above calculations indicate that a CAD system does 
not require very advanced or large-scale data processing equip- 
ment. A standard minicomputer is mure than adequate for a 
system of the size assumed in the example, and with added 
peripherals could handle a considerably larger load. The equip- 
ment requirements for the example can be summarized as 
follows: 


Computer Standard 16-bit minicomputer with 
3-micrusccond cycle time 

Core storage I6K words ititegrul witli computer 
plus three additional I6K modules 
(64K total) 

Disc storage One 25-megabytc unit 


♦ The sizes Ilf core buffers arcdelcrmincilbytlie number of terminals, 
itigiial eonuminication lines, peripherals, amt inessage/iransaclinn 
rates estimated for the example system. 


62 




r,* 

r 


Cungery 

Cort Imsflt progrimi 
Opirtiing lyttem 
*04t-llne uiir progmmi 
I/O racovery <6 mlnutei of data) 

*Ma>ter ttreat file 1676 itreet block facet per stiuere milel 
*Straat Index 1166 itreet nemei per iquira mile) 

* Landmark file 110 landmarki par iquera mile) 
*Telephone directory <160 telapnonail 
‘Addren Intelligence (200racordi) 

*Temporary situation file <100 racordi) 

Deployment ichedula (460 records) 

System access author liatlon (460 records) 

**lncident log (10 hours) 

**lncldant summary (lOftouri) 

Patrol unit status (200 records) 

'Operator activity (40 records) 

‘Patrol unit activity (200 records) 

‘Radio-talaphona statistics (24 hours) 

Total 

Total with starred files omitted 


Maximum File Raquirameni 
(1000 bytes) 

64 

126 

32 

1,742 

12,844 

7,977 

190 

12 

49 

16 

57 

39 

645 

62 

3b 

23 

186 

6 _ 

24,328 

2,992 


‘Optional files (sea Section 6.2 for contents). 

“The number of hours logged on disc for quick access review 1s optional. The 10-hour capability allows for the second 
shift to review ell Incidents processed end deferred by the previous shift. 


Peripherals One card punch (100 per minute) 

One card reader (300 per minute) 

One line printer (600 lines per 
minute) 

One typcwrltcr-typeprintcf per dis- 
patcher console (per two positions) 

One microfiche file and viewer per 
console (two positions) 

This brief list covers only the data processing equipment. 
A more complete list including communication interface equip- 
ment will be found in Table 1 7 (Chapter 7). 


6.4 Planning Trade-Offs 

We have already identiHcd certain features of a CAD 
system that Involve trade-offs of one characteristic against 
another; most often these reduce to a question of performance 
versus cost, althougli there are other characteristics that can 
enter into the selection of a particular system design or con- 
figuration. This section discusses some of the trade-offs that a 
planner may need to consider in addition to those already 
mentioned. 

6.4.1 Dedicated vi. Shared Computert 

In a city where the city government already has exten- 
sive data processing facilities, it may he feasible to consider 
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huving » CAI) xystcm hccomu one ii»icr i>t' these I'ucilitleH 
insteud of ucc|uiring its own data processing liardware (it would 
still need Its own consoles and terminals to Interlace with the 
central facility). The considerations involved in this liadc*ol'f 
cun be snmmarl/.ed as follows; 

Advantages 

• I’otcntial saving in cost and time of implementing 
u CAD system. 

• Potential saving in maintenance costs (which would 
be shared). 

• Potential saving in cost of developing and main- 
taining software (if existing DP staff can handle 
these functions). 

• Potential saving in equipment and manpower 
required for off-line (non-real-time) operations 
such as generating management reports, tape log- 
ging, and record keeping. 

Disadvantages 

• Department does not have the system under its 
own control and can influence performance only 
indirectly. 

• The central facility may not be set up to provide 
support 24 hours a day, .365 days a year at the 
required level of priority. 

• Coordination of CAD hardware and software main- 
tenance is more cumbersome. 

• Ceitral facility may not be in compliance with 
stale and federal data security regulations for law 
enforcement data records. 

• Tile potential cost saving may not be rcali/.ed 
because the CAD system vendor does iiot have full 
access to the c“ntrai facility during the develop- 
ment, integration, and test phases of the new 
system. 

• The potential cost saving may prove to he rela- 
tively small because of the declining costs of mini- 
computers suitable for (‘AI> systems. 


6.4.2 Minicomputer vt. Large Main Frame Computer 

The question of using u large main frame computer for 
the CAD system may arise in police departments that are plan- 
ning to iinpleineni several automated functions in addition to 
a CAD system (e.g.. automatic veliicic location, digital commu- 
nications). Only a complete analysis of requirements for all the 
proposed automated functions in relation to the capabilities 
of alternative hardware configurations could provide a good 
basis for making this decision. 

It should be noted, however, that the present technical 
trend is toward distributed computing networks using multiple 
minicomputers. Tliis trend results from recent improvements 
in llie overall system reliability and performance of minicom- 
puter systems, combined with generally lower costs for a given 
capability. 

6.4.3 Single Processor or Redundant Processor 

riie systems described in previous chapters liave gener- 
ally been shown witit two CAI) processors, one of them redun- 
dant. The question may arise as to whether there is a firm 
requirement for this 100 percent backu]) capability, particu- 
larly since the availability factor lor typical commercial mini- 
processors is in the neighborlmod of O.OOgn (about 2 minutes 
a day or 12 hours a year of down time). Nevertheless, this fig- 
ure includes an average repair time of K hours, whiclt may be 
more than a department wishes to tolerate. Duplicating the 
processor brings the figures to O.yO'WO, which means less than 
one second per day or 5 minutes a year of down time. 

lliese figures are for the processor alone. I'or a twrv 
processor system plus the power source and the terminals 
(assuming some of the terminals can be used to back up the 
others), the figure is more like 17 seconds a day or just over 
1.7 hours a year. 

Another consideration is that the redundant processor 
can be used for off-line functions, such as generating manage- 
ment reports or training operators, without interrupting the 
regular operation of the system. The redundant processor can 
also be placed on-line for load .sharing of iransaclions; tills 
mode of operation would require an additional software pro- 
gram at the operating system level to coordinate each proc- 
essor’s activity. 

6.4.4 Singla vs. Dual (or Mora) CRTs on Dispetchar Coniolas 

The advantages of multiple ( RIs on dispatcher consoles 
were discussed in earlier sections; in general, having more infor- 
mation on permanent display reduces the stress level of the 
dispatcher and simplifies his tasks. Anotlicr point to be con- 
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sUleiccl is tl»;K if (lie patrol units luive tlif capalrillty oC rlliactly 
iipilallnn the patrol unit status display hy dlttilal aommunlcu- 
tions litiks, the patrol unit status display should he pernia- 
nently oti the screen: otherwise the dispatcher would not he 
aware of status changes without additional provision for Hash- 
ing the display, liven with this provision, the stress level would 
probably be higher than if the patrol unit status display were 
continuously present on a screen. 

6.4.6 "Smart" Terminals vi. Standard Terminals 

lor our purposes, a “smart" terminal is one that has the 
following capabilities located in the console: 

• At least tW-5 full display pages on its local memory. 

• Capability for entering and editing display informa- 
tion on the locally stored pages. 

A standard terminal has none of these capabilities except 
that it has the refresh memory for the display on its screen or 
screens. All display changes are executed by the central proc- 
essor and transmitted to the terminal, 

Hie advantages of the smart terminal are; 

• Makes changes in display or keyboard software 
easier to implement, 

• Reduces the work load and I/O requirements on 
the central processor. 

• Permits a degraded mode of operation if the proc- 
essor fails; the dispatcher is still aide to maintain 
his patrol unit status display and his incident sum- 
mary data for local update and terminal-to-terminal 
message exchange through appropriate patching at 
the multiplexer assembly. 

The cost of smart terminals has decreased steadily as a 
result of the introduction of microprocessors; their use should 
be givcti serious consideration by the planner. 

6.4.6 RetpontB Time Trade-Offi 

Some of the design decisions to be ttiade tor a CAD sys- 
tem involve an increase in response time with a correspoiiilitig 
reduction in equipment size, complexity of software, and costs, 
A few such trade-offs are brlelly disctissed below. 

ihta l)ramfer Rates. The lime required to generate or 
update a display is affected by the data tratisfer rates from 
tlie processor to the display. A standard serial data interface 


can transfer u full display of I‘i2() k-hlt characters Iti l.b sec- 
ontls ('>(>()() Itits pe' secomi). A more expensive byte iiarallel 
buffered direct ttiemory can generate a full display In .TK 
milliseconds, 

Core I'.v, Dise Memory, It is imssible to reduce the core 
storage requirements by having more data stored on disc, with 
a consequent increase in system response time because the data 
mtist be transferred from tnere instead of from the direct- 
access core. 

Firmware v.t. Software. I'irmware is the term for 
frequently-used routines that are programmed in a read-only 
memory and executed much faster than if programmed in the 
normal manner under processor control. Ixamplcs of routines 
that arc amenable to firmware are communications I/O han- 
dlers that always perform exactly the same function. 

i'roitramming I.anguage. Higher-level laitguages such as 
FORTRAN, Basic and COBOL are advantageous from the cost 
and convenience stiuulpoints during development and for soft- 
ware maintenance; however, program execution times (and 
therefore system response times) arc improved by programming 
in assembly iaitguuge. Object code execution time typically 
increases by a factor of I ..S for a routine coded in a higlier- 
level language rather than in assembly language. Run-time 
executions of higlier level coded programs have even greater 
execution time penalties. 

Drum vs. Disc Storage. Response time can be improved 
by the use of drum storage devices rather than disc storage, 
but the large increase in cost is not likely to be worthwhile for 
a CAD system. 

6.4.7 Future Additioni to the Command and Control 
System 

I'liture additions to the command and control system 
that the planirer may be considering, and that have a direct 
effect on the design of the CAD system, are briefly disenssed 
below. 

y/ / ANlf.At.f. The nationwide emergency nnmber ‘Ml. 
as it is gradually implemented, can include a feature that 
may improve incident processing time significantly. I'his is 
Automatic Number ldcntincatio:i (ANI) and Automatic Loca- 
tion Identification (Al.t). Wlierc this interlace is available from 
the telephone company, it provides automatic identification 
and display of lire calling telephone and its location. This 
information is displayed on tlie (TIO console ami automati- 
cally becomes part of the incident data transferred to the diy 
patcher. I'his feature is especially attractive for dispalchitig. 
since it lias been determined tliat about StI to ')() percent of 
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iiicUlciilH reported ure rit the saiiie loeiitioii as the telephone 
used to report them or within a lew houses ol' the telephone, 
This not only saves the time orenleiiiiH the data, hnt simplil'ies 
the address and inrisdletion veril'lealion hy the syslein. 

Automatic Pativl Unit Statux Uptime. Where patrol 
tlilits are equipped with mobile dlidtal terinitials with two-way 
diititul transmission, it is possible to have the patrol units trans- 
mit digital status messages directly to the processor (through 
appropriate logic and switching circuits), which updates the 
status displays. This reduces the load on tiie dispatcher, who 
no longer has to listen to voice status messages and enter the 
status change on the console keyboard, it also reduces the 
voice chanitel loading. If the system is to be implcinentcd at 
the same time as the CAD system, or if the ileet is already 
equipped with two-way mobile digital terminals, this reduction 
in workload can be included in the system sizing calculations. 

Direct Data iiaxc Queries. I'his is another capability that 
can be provided if the patrol units are equipped with two-way 
mobile digital terminals. Through appropriate swilcliing cir- 
cuits in the command and control center, patrol units can 


liaiiKmit (jiieries directly to the remote data base and receive 
the replies directly on their mobile terminals, litis results in a 
significant reductioti in ilispateher work loatl if the ilispatcher 
is handling these tpieries, and system sizing calculations should 
lellect the icduction. Where this capability is provided, how- 
ever, provision is also made for automatic logging ami printout 
of any *'hit" respmisesi sucli provisions must lie included in tlie 
system design. 

Auiontaiic Vehicle Location. There are several diflcrcni 
technu|ucs for airtomatically deterntining the position of all 
vehicles in the tleet and transmitting this information to the 
command and control center. Where such a system is imple- 
mented, it reduces the work load on the dispatcher by elimin- 
ating the task of updatitig the patrol unit status file. It also 
helps him locate more quickly and ci'ficicntly the nearest unit 
to an incident. 

Must techniques for automatic vehicle location require 
extensive calculations, which should be handled in a separate 
processor. The planner shoidd not expect to have the ('AD 
processor handle this additional load. 
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7. PLANNING GUIDELINES! PREPARING THE IMPLEMENTATION PLAN 


The planner consUkrlnglmplemciitatlini til a(‘AI) Hyslem 
for his rlepartnient will nceil to prepare an iinpicmeniullon 
plan. This plan Is a systematic way of identlfylnn Ihe things 
that must he done to make the new system operational, and of 
evaluating the costs and other eftects of each step in the Imple- 
mentation, It may even he deslrahlc to prepare two or more 
alternative implementation plans as a basis for making a 
thorough comparison of two or more different systems or 
configurations of a given system. 

The major ciements of the implementation plan arc an 
overall schedule and a funding plan. The schedule should have 
at least the following major activities on it (with suh-elements 
where appropriate): 

(1) Precontract phase, 

(2) Procurement of the system. 

(3) Facility preparation. 

(4) Installation and checkout of equipment. 

(5) System demonstration and acceptance. 

(6) Personnel training. 

(7) Maintenance. 

Other items that may be required in some cases are; 

(8) Agreements with other local agencies that may 
be affected. 

(9) Connections with remote data bases (local, state, 
federal). 

(10) Time-phased implementation (some optional fea- 
tures or additional capacity to be added at a later 
date). 

(11) Implementation of a CAD as part of a complete 
automation program for the department or agency, 

The funding plan should show complete cost estimates 
for all items of expense plusa breakdown of anticipated expen- 
ditures by fiscal year from Ihe start of funding to completion 
of system Implementation. It should also cover expected main- 
tenance costs. The elements to be identified in the funding 
plaii are in general; 

(1) The department (or other local agency) program 
management office, 

(2) Consulting or systems engineering support, if sucli 
support is planned. 


(.t) Procurement of ei|uipment and software. 

(4) Facilities acquisition and preparation. 

(5) largistics (training, maintenance). 

A sample implementation plan is given below to illustrate 
the above points. It covers implementation of the CAI) system 
described and si/.ed in Cliapter 6, The planner will piolrably 
wish to add more detail to the Irasic plan given here as an 
example. 

A CAD system is most often procured as a turnkey 
system provided by a single vettdor tor a stated price. Never- 
tlieless, the procuring agency will want to specify the com- 
ponents of tlie system. 

A private firm may be contracted to perform an 
analysis of requirements, generate system preliminary designs, 
and prepare specifications. 

Table 17 is an equipment list for the example. Note that 
monthly maintenance costs arc included in the cost estimates. 
The maintenance cost provides for full-service coverage 
24 hours each day and includes replacement parts, sclicdulcd 
preventive mainienuncc, and factory updates on the equipment 
item concerned. 

Figure 16 isa top-level schedule for implementing a CAD 
system, listing the major activities with their start and end 
dates. 

Summary costs for the complete system implementation 
are given in Table 18. The elements in the table are defined 
as follows; 

Pntgrani Management Ofjtce, This item covers Ihe cost 
of setting up and maintaining, within the procuring agency, 
a program management office of six persons. This stall is 
responsible for preparing the request fi>r bids, evaluating the 
bids received, maintaining the interface witli the selected 
vendor, and coordinating the CAD system implementation 
with the day-to-day police operations and with any local 
government personnel involved in the implementation. 

Travel, This sum is provided to cover the travel 
rcrpiired for consultation with departments in cities that have 
already impicmeirted CAD systems, and any required travel to 
thi vendor’s plant. 
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1. 

CAD minleompuMr with 18K wordi o1 
cora and ilandard optigni (povvar fall, 
raal tlma clock, atc.l 

2. 

16K word tncmorv add>on fnodulai; 
3 aach/prooanor 

3. 

Direct mamery Kcaii unit 

4. 

Dual CPU Intarfaca unit 

6. 

Mamory protect unit 

e. 

Interrupt axpantlon chaiili 

7. 

Communication multiplexer 

8. 

TTY with paper tape raad/punch 

9. 

Dual accaii 26 meoabyia dlie 
controller 4 2 28 Mbyte Nrvoi 

10. 

Card punch <100 CPM) 

11. 

Card reader (300 CPM) 

12. 

Una printer (600 LPM) 

13. 

Magnetic tape (76 IPS, 800/1600 BPI, 
9 track) 

14. 

Time coda generator 

IB. 

Coniote printari 

16. 

CRT/KB terminal liingla CRT) 

17. 

CRT monitor (for dual CRT coniolei) 

18. 

Conielai/radio twitching 

16. 

Interlace ilgnat conditionar/buffar 
multiplexer (32 channel i) 

20. 

MlKallaneoui cabling and ctblneti 

21. 

Uninterruptable power lynami 
(U.P.S. 10 KW) 

22. 

Modem 2.4 K BPS 

23. 

MIcrotiche vlaweri 


Qly I UnltCMt.lK I TaulCoit.tK Unli Monitily Mtlnlmnc* Cm«, I 


Equipmini Totalt 
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fUNDINn AfflIOVAt 
PUfCONIIIACt ACKVIfV 
KlNRTinNAI APtjfi 
mAARE Iff 
AAHirVAl 10 irA 
AtOAUSAIi RECEIVED 
CONlRACtOR lEllCflON 
CONIRACI ilONEO 
EYStEM DESIGN 
AREIIM, DESIGN REVIEW 
EACIlltY PREAARAIION 
EUUIAMENI INStAUAtlON 
tGJIAMENI TCSI 
SYSTEM lESI 
SS'SIEM ACCEAtANCE 
AERSONNEl IRAIN 
OAERATIONS TRAN SEER 
MAINIENANCE CONtRACr 



Pig. 16. Ovtrall ichMiult of ictivltlti 


Facilities, It is ussiiincd that the cotnmand and cotitrol 
center using the new CAD system will be housed in new or 
remodeled quarters. The cost estimate includes air condition- 
ing, smoke and fire detection system, raised floors to allow 
cabling between consoles, computers, and other etiuipinent, 
and the required power supply and grounding system. The 
changeover from the old to the new system is simplified by 
having tlie new system in a separate facility where it can be 
thoroughly checked out and the personnel trained before the 
transition is made. 

System CotitractorlSystem I’rocurement. Tltis item 
covers all the costs of procuring the completely installed and 
checked out system from the vendor. 

Items Not Slit/w/t, .Some costs that must be allowed for 
but for which ilo costs are estimated because of the wide 
variation in possible costs are; 

• Telephone equipment and leased lines required for 
the new facility over and above those currently 


used (duplicate costs will be incurred duriitg the 
period when both old and new facilities are 
operating). 

• Relocation or replacement of office equipment. 

• Supplies (tape reels, printer paper and ribbons, 
spare disc packs, etc.). 

• Agency personnel costs in developing data files, 
training scenarios, etc. 

Naturally the equipment and other costs shown here 
may vary since prices can change quickly and the prices shown 
are catalog prices that may be subject to discounts. The 
planner will have to develop his own estimates, and fur this 
purpose will find it indls|)eiisiblc to talk with de 'artments in 
cities that have implemented CAD systems of theii own. It will 
be most useful to contact cities oi' comparable si/.e and having 
systems similar to the one (or ones) he is considering. 
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Tilil* II. lyittm Ifliiilimtnutlon Goii litimwM 


linn 


Proflrim miniBtmtni ofllo* 

(•I Senior Potlfl* Of 1 leer 

|b| Police Officer 

le) Adminlitretive Anelyit 

(d) Communicetloni Engineer 

(e) Date Proceiilng Engineer 
If I Clerk Typlil 


30 monihi X 13,000 
30 monihiX 1,400 
1/3 lime 30 ntonthi X 1 ,800 
30monthi X 1,600 
30 monihtX 1,800 
30 momhi X 760 

Totrl lelerlei 

Employee benef Itt 130% of telery) 
Total perionnal tervicai 
Office equipment and luppllei 
Total program management 


Travel 

Facility (upgrade) 

Syitam contractor/iyttem procurement 

(a) Hardware development and teat 
(30 MM* »$3600/MM) 

lb) Software development and teit 
(70MMS>$3600/MM) 

l c) Equipment coit (Table 1 7 1 - 9-month maintenance) 

(d) Equipment procurement and traniportatlon 

(e) Engineering larvlcai (24 MM S> S3600/MM) 


Training 
Acceptance teit 
Pheitt over + monitor 
Documentation 
Mlicellaneoui 


6MM 

3 MM 

6 MM 

7 MM (equivalent) 

4 MM 


(f) Travel and lubilitence 

(g) Program manegement (20% direct labor coat) 

(b) Contractor (laed fee 1 1 0%) 

Total Syitem Contractor Colt 
Total Ettimated Coit 
6. Equipment maintenance (per year) 


*MM “ man-month 


8 80,000 

43.000 

34.000 

64.000 
64,000 
23,600 




iORlGINAt, PAGE IS 
fOF POOR QUAU'fY 
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8. PUANNINQ QUIDELINESi COST BENEFITS ANALYSIS 


TIk' detlxUm by tin iineiicy to piirclipe u tiominilCMilil«<l 
JlHpiitdi sysicn will be Klfoiinly Inlluciiceil by uii ovcnill evulu- 
lit Ion of eoNts vs. bcncl'iis. inirtlculnily linn or "hurd" boiiel'lts 
thut lire visible to ii»ency niiinu«ers In the form of rediieed 
costs. We cim list u mimbcr of beiicflis ihiit cun be expected 
to follow from the Implemcntiition of ii ('AD system, based 
on the general goals of computer-aided dispatebing, whlcli urc: 

• Increase the efficiency of command center opera- 
tions by providing: a real-time capability lor enter- 
ing and updating Incident infarmatlon. dynamic 
displays of field units available for dispatch, real- 
time displays of service cull backlog, and a luster 
means of getting supporting infornuition to the 
field officers. 

• Increase the efficiency and safety of ibe patrol 
officer by getting him more infoniiallon in a 
timely manner and minimizing bis paperwork, as 
well as the paperwork of the entire operational 
staff. 

• Provide near real-tiinc management inforination on 
the patterns of crime and other incidents, on the 
utilization of field Ibices, and on the general oper- 
ational effectiveness of resource utlliz,ilion. 

Specific benefits that can be identified from the getieral goals 
include: 

( 1 ) Improved officer safety . 

(2) Keduced crime rale. 

(.^) Shorter response time to citizen calls, 

(4) Reduced paperwork load on field officers. 

(5) Reduced paperwork load on command and con- 
trol center personnel. 

(fi) ^'asler and more complete inlorinatlon on crime 
patterns. 

(7) 1-aster and more coiniilete Inforination on patrol 
force activities. 

Improved ulili/atlon of field forces. 

(0) Improved utilization ot command and control 
center personnel. 

(10) Improved Interface with the community, and with 
other agencies. 


Not all of these factors, and certainly not Ibe most 
Important of them, can be expressed In dollar terms, Our 
approach will be to compute dollar values where possible, and 
to indicate (pialllatlve benefits thut are claimed or have been 
demonstrated for (‘AD, 


Of the benefits listed, items .1, 4, and 5 can be ipiantilted, 
and give some Indication of the Improved utilization of Ibid 
and command and control center personnel, items K and ‘f. 
Improvements in these items will have a posllivc effect on the 
otirer factors mentioned, but the effects are dillicult to quan- 
tify or convert to dollar values. The Impact ol changes In patrol 
operations on factors such as crime rate and community rela- 
tions is difficult to measure even in carefully controlled 
experiments, and too little data exists to form a good basis for 
developing trade-offs ol personnel utilization vs. reduced crime 
rate, etc. 


Two agencies have evaluated their CAD systems and 
developed estimates of cost savings; these agencies arc the 
Huntington Reach Police Uepartment (llHPD).and a consorti- 
um of three departments, including Oak Park, River f-oresl and 
forest Park, Illinois, that operates a cooperative dispatch sys- 
tem ( Appendix C). Summaries of their evaluations arc presented 
In Tables Id and 20. Both summaries apply to CAD systems 
serving populations of 1 .SO.OOO (tbe tlirce-departnienl coopera- 
tive CAD system serves an actual population of 92,000, but 
tlie results have been adjusted for purposes of comparison). 
The estimated savings for the three-dcpariinent system are 
considerably higher than those for IIBPD, $lf>S,K40 per year 
vs. S22,920 per year. The difference lies primarily in the esti- 
mated savings for preparation of unit activity reports, it is 
assumed that activity reports for field units arc generated en- 
tirely by the computer for the tliree-departinent system at a 
saving of 15 minutes per report (4.t,KOO reports per year), vs. 
asavingof 2,9 minutes per iitcUiciu for the 1IBPD(47,000 inci- 
dent reports per year). The higlier estimate may not be realiz- 
able in actual practice because field officers must dictate 
notes to a transcriber in lieu of written reports. Tlie two esti- 
mates should represent minimum and maximum cost savings 
for this function. Both agencies enumerate otiicr areas for 
potential cost savings, primarily in the preparation of manage- 
ment reports (UCRs, inddenf patterns by beat, time of day, 
etc.). Much or all of the data base for tlicse reports is captured 
by the computer and it is relatively slraiglrtforward to 
Implement a report generation capability. 
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Tibia IB. Con Biniflti Analyili for Huntington BiKh BoHoa Oigartmint CAO Syritm* 
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Tub!! 20. Cpit itntdil Anulvili for • MHltlH|onov CAO tyitom* 

Syitimi Miililn(i*nBvCADivitimiirvln 0 s«omblMrtpopu)«ttonof 190,000 


SRvingii 


$200,000 


Termtiiolf amt rrfriilume tines. A iivlna li by cancollnB iht Ium on tho wrmlnal dawict oonnaetad 
to tha iiata crlmlnat juitica Information lyitam; connaotlon It mada through tha AID Syitam. Thara It 
alio a Hvlng on tha Itaiad talaphona llnai. Tha laaii of tha tarmlnai davica and talaphona llnai It 
aitlmatad at $2B0 par month par city. Tha coit of tha AIDS talaphona llna It aitlmatad at $1 BO par 
month. Tha aitlmatad lavIng li: 

(3 X $2BO) • $1B0 > $600 par month 

Imkx cards. Many of tha data Itami (nama, data, tima, location, typa of Incldant, Incldant numbar, 
itolan proparty, ale. I which ara Indaxad from Incldant raporti for antry Into a racord lyitam ara 
capturad by AIDS during tha normal dlipatch oparatlon. Itami not eapturad during tha dlipatch oper- 
ation ara added through tarmlnali. Procedural are provided to permit lamlautomatic printing of 
nama, Incldant, location, and property Index cardi. Tha aitlmatad lavIng In 

(too Incldanii par day I X 10.1 hour of clarlcal time lavad par IncidantI X ($4 par hour) 

' $40 par day or $1 ,200 par month. 

Unit aclMiy report. The AID Syitam prititi out unit activity raporti for aach patrol unit par 8-hour ihift, 
Thti report allmlnatai tha need for officari to lubmlt a handwritten raport that a ciark muit typa and 
file, Aiiuming 30% of 360 iworn perionnal ara raqulrad to fill out report!, tha coit lavIng ii aitlmatad 
at: 

360 officari X 30% X (0.26 hour par raporti X ($7 par hour) ■ $169 pat day or $6,670 par month. 
Tha clarlcal lavIng It aitlmatad at: 

30% X 360 officari X (0.26 hour par raporti X ($4 par hour) - $180 par day or $3,240 par month. 

Daily log. The AID Syitam primi a dally log for all activltiai. Tho aitlmatad lavIng It computad ai; 

(3 aganclei) X (2 hour# par agency par day) X ($4 par hour) * $24 par day or $720 par month. 

Ticket listings. The AID Syitam generatai a lilting of all dlipatch tickati ai often ai raqulrad. Eitimatad 
laving » (3 aganclei) X (2 houri per agency per day) X ($4 par hour) “ $720 par month. 

kfanogement report. The AID Syitam prlnti out managament raporti on dapartment activity on a daily, 
weakly, and monthly baili. Eitimatad lavIng *» 3 aganclei X (160 houri par agancy par month) X ($4 per 
hour) ° $1,920 par month. 


Total lavlngi for thli hypothetical Initallatlon ara: 

Tarmlnali and talaphona llnai 

Index cardi 

Unit activity raporti 

Dally log 

Ticket lilting 

Managament raporti 


$ BOO 
1,200 
8,910 
720 
720 
1,620 

$ 14,070 par month 
$168,840 par year 


•Based on the Automated 'll•^roctivo Dlipatch Syitam (AIDS) for Oak Park, Hivar Forait, and Forait Pert. Illinoli. 
naferance: A.B. Carroll, at al., Computer-Aided Dis(Mtching for l-aw fn/orvement Agencies, Community Technology Inc. 
Champaign, Illinoli. 
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We cun cstimiitc ihe cost suvlnps I’nr otir example (’Al) 
system ilesl(tnocl to serve a population of one million by seal* 
ing the values slven In Tables 10 anU 20. The potential savltigs 
arc in three main areas: 

(1) Dispatch operations. 

(2) Preparation of ficlil activity reports, 

(3) Preparation of managemettt reports. 

The first item accounts for the amount of time saved in 
prrrcessing calls for service and dispatching field units, I'he 
estimates for 1 1»PD are used, scaled on the basis of population; 

.‘5,122 hours X $5.74 per hour » $20,400 per ycai’" 

In addition, a small amount of time is saved for address verifica- 
tion and beat number look-up. An estimate of 8 seconds per call 
has been made for this function based on studies of the Los 
Angeles PD operations, Por one year of operation: 

81 1 hours X $5.74 per hour = $4,650 

The HBPD value of 2.9 minutes per incident reduction in 
field officer time for incident report generation is used for 
item 2: 

14, 1 20 hours X $9.75 per hour = $ 1 37,700 

This savings is reduced, however, because of the addedcost for 
transcribers who receive the telephone reports from the field 
officers: 


8,077 hours X $5.74 per hour « $46,400 
leaving a net saving of $9| ,300 per year. 


Management reporting at HBPD requires approximately 
40 hours per week. It is estimated that one-half this time cun 
be saved by a computer report generator. For our city of one 
million population the contparabic saving is: 

6,930 hours X $5,74 per hour = $39,800 per year 


Tltis gives total savings for alt three items of: 


( 1 ) 

Dispatch Operations 

Savings per year 
$34,050 

( 2 ) 

Field activity reports 

91,300 

( 3 ) 

Management reports 

39,800 


TOTAL 

$165,150 

Over a 5-year period, these savings amount to: 


$165,I50X5 = S825,750 


This saving compares to our implementation cost estimate of 
1.84 million dollars. If the hi^ier value of cost savings for 
item 2 were used, based on the three-department cooperative 
CAD system, the total 5-year savings would increase from 
$825,750 to over 3.9 million dollars. 


*l,alHir rate* used are based on IIHPI). 
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APPENDIX A 


PARTIAL LIST OF COMPUTER-AIDED 
DISPATCH SYSTEM DESIGN AND EQUIPMENT 
MANUFACTURING COMPANIES 


Kuiitom Data Communications, Inc. 
1010 W. Chestnut 
Chanute, Kansas 66720 

Motorola, Inc. 

1301 U. Algonquin Road 
Schaumburg, Illinois 60172 

General Electric Co. 

Lynchburg, Virginia 24502 

PRC Public Management Services, Inc. 
7798 Old Springhousc Road 
McLean, Virginia 22101 

Boeing Computer Services, Inc. 

P.O. Box 708 

Dover, New Jersey 07801 


i 

I 

i 

] 
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System Development Corp. 

2500 Colorado Avenue 
Santa Monica, California 90406 


Public .Systems, Inc. 

1137 Kern Avenue 
Sunnyvale, California 94086 


E-Systems, Inc. 
Garland Division 
Box 61 18 

Dallas, Texas 75222 


Sunrise Electronics 
P.O. Box 163 

Earmingdale, New York 11735 
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APPENDIX B 


1 

I 


HUNTINGTON BEACH POLICE DEPARTMENT COMPUTER-AIDED DISPATCH SYSTEM* 


1 , Introduction 

The IIBPD services » rapidly growing city in the Orange 
County metropolitan area ol‘ Southern California. Its popula- 
tion in 1973 was 150,000, approximately 10 times greater 
than its I960 population. Huntington Ueach has a large daily 
influx of people during the summer months, so that the popu- 
lation actually served by the Police Department may be dou- 
ble the number of residents. The city covers 27 square miles 
and has relatively few topographical features that impede 
communications with its mobile fleet of 22 units (average 
deployment). 

The IIBPD received 57,000 calls for service in 1973. TWo 
dispatchers and one complaint board operator are normally on 
duty to handle these calls and control the mobile units. 

2. Computer-Aided Dispatch and Mobile Digital 
Terminal System 

Huntington Beach recently installed and placed in opera- 
tion an advanced computer-aided dispatch (CAD) and mobile 
digital terminal system. This system has proved highly satisfac- 
tory in operation, and is described in some detail to acquaint 
the planner with its characteristics and capabilities. A scenario 
depicting the sequence of events and dispatch and status dis- 
plays during an incident (in this case, an armed robbery) is pre- 
sented to better illustrate the operational procedures of a CAD 
system. A layout of the facility is shown in Figure B-1; Fig- 
ures B-2 • B4 present details of the operator stations and 
microfiche unit. 

The computer aided dispatch system consists of a computer 
and keyboard/CRT terminals which enter, store, and display 
information relating to the incident, the status of the mobile 
units, and actions taken by the dispatcher to service calls. Hard 
copy printers provide permanent records of all transactions. 

The mobile units are equipped with Motorola MODAT dig- 
ital terminals through which the officer can indicate his status: 
Available, Hnroute, At Scene, Investigating, Returning to Sta- 
tion. Mobile teleprinters in the mobile units receive dispatches 
and other Information normally relayed by voice. Patrolmen 
make all other transactions by voice, fhe MODAT unit is 
shown in Figure B-5. 


When a cili/eii phones In a complaint, it is taken by a com- 
plaint operator, who types iti data at a ('RT/keyboard. Hie 
data enter the main computer, wliich creates an incident record 
for that incideiu. The address and intersection arc sent via 
phone lines from the police computer to a central computer 
located at the city's Data hoccssing iXpartmcnt; tiie latter 
computer contains a geographic file, including beat number 
for the location. These data arc sent back to tlic police 
department for display on the dispatcher CRT screen. 
The status of units assigned to the identified beat 
is displayed on another screen. The dispatcher assigns 
a unit, types the data into a computer, and notifies the 
unit by voice-radio. Tire computer simultaneously sends 
a digital message to the unit’s teleprinter, giving dispatch 
data about the new incident and historical data obtained 
from the geographic file. 

Fach unit has a status terminal which permits the patrolman 
to send a change in status, via digital radio, to tlie police 
department computer. Tlie computer maintains an up-to-date 
table of the status of each unit. 

The IIBPD has incorporated silent alarms into the CAD in a 
unique manner. If a silent alarm sends a signal to the police 
department, tlie computer sends a canned message of data and 
advice to the units assigned by the dispatcher. Tlie Huntington 
Beach I\)lice Department has linked its silent alarm system to 
the CAD and to a microfiche file. Alarms show up immediately 
on dispatcher consoles. In addition, the microfiche file con- 
tains location, interior and exterior layouts, aerial photos, loca- 
tions of protection devices, and hi^iway blockade positions 
of each alarmed site. A dispatcher can study the fiche display 
and guide a patrolman via portable radio to a particular loca- 
tion (see Figure B-4). 

Requests for data base queries arc given by voice-radio to 
the dispatcher by the mobile unit. The dispatcher enters the 
request (e.g., vehicle license number) by keyboard, and the 
police department's computer sends tlie request to tlie rcMnote 
data bases. Responses from the data bases are displayed to the 
dispatcher, who relays the data to the mobile unit by 
voice-radio. 

Operational data are captured by Hiinlingtoii Beach lot 
management repotting purposes, ( iitretilly, tlie daily logs of 


nVc wish to extend our appreciation to Hie personnel of tiie HimlinKlon Heueli Iblice Deparltnenr lor llieir assistance and coopLralioii in pieparin,- 
this Appendix on coinpiiter-uided dispatch. 
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inddeius are lypetl out automatically by the computer; how- 
ever, tlctalletl management repotting will not be placed In 
operation for about a year. 

3. Radio Syttam 

Hie !1BH) recently Installed a IJUF radio system consistent 
with the county-wide police radio plan (Orange County). Ihe 
county allocates the rrci)uencies lor all police departments in 
accordance with a master frequency allocation plan. 'Ibe police 
channels are in the 455 - 460 Mllz range. 

The cliannel assignments for the HBPD arc shown in 
Table B-1. The Orange County communications net provides 
intra-county links and access to the California Law Enforce- 
ment Telecommunications System (CLUTS). Through CLUTS, 
data base queries can be directed to person wants and war- 
rants, stolen vehicles and Department of Motor Vehicles files 
at Sacramento, and to NCIC and NLliTS. The Orange County 
Criminal Justice Information ^stem also can be accessed on 
this frequency. 

One base station transmitter site Is connected by land line 
to the command center. No satellite receivers or microwave 
links are employed. Five portable radios are used per shift. 

4. Example of a Computer-Aided Dispatch 

An example of a computer-aided dispatch was conducted 
by the HBPD to demonstrate the operational procedures they 
have developed to utilize this new capability, and to illustrate 
the sequence of CRT displays and formats used by the com- 
plaint board operator and dispatcher in handling the incident. 
The CRT displays are perhaps the most important feature of a 
computer-aided dispatch system because the operators enter 
and receive all necessary information from these displays; 
cards, status boards, conveyor belts, and other traditional dis- 
patching aids are eliminated. All activity now focuses on the 
CRT displays. 

All inputs to the CRTs must be entered via keyboards. 
Sonre information is entered by the operators as the incident is 
being handled; other information has been loaded into the 
data files prior to ilie incident and is recalled by the operators, 
«rr automatically by the computer if it relates to tlic current 
incident. In a sense, this procedure is a “new way to riiti the 
railroad,” and requires some reorientation on lire part of 
operations personnel. 

The process of entering all data into the computer system 
via keyboards gives the CAD system a major advantage in tliat 
data relating to all incidents and field force operations (activi- 
ties, times, alli'cations of forces, incident rates, and locational 


patterns) can be processed automatically by the computer and 
printed In convenient reports for use by operations and man- 
agement personnel. Ultimately, f^Al) should contribute to 
more cfftclent use of manpower and mobile forces, enhanced 
ofllcer safety, redueed workload on operations personnel, and 
belter management reporting because of reduced clerical work- 
load and time involved in statistical report preparation. 
Hie degree of the advantages offered by CAD systems has 
not been established because of toe newness of the innovation, 
but the potential is evident. 

Hie lIBPDIias identified a number of udvaiitiiges ofl’ered by 
CAD, primarily relating to the reduced workload for entering 
and capturing data concerned witli operations. These time 
reductions include; 

(1 ) Recording incident response times 

(2) Bntering file numbers 

(3) Typing radio logs 

(4) Updating unit status 

(5 ) Recording unit status 

(6) Entering complaint information 

(7) Transferring complaint data to dispatcher 

(8) Sorting incidents by area and priority 

(9) I^trol unit status change (by patrolmen) 

(10) Writing dispatch information (by patrolmen) 


Tsbl* B-1. HBPD Channel Anignmtnti 


Channal 

Name 

Number 

Um 

Bate Frequency, 
MHt 

Graan 

1 

Local voice channel (diipatch- 
ing plus digital ttatus) 

Duplex, 460.1 

Orange 

2 

Tactical frequency Unking 
other departments in that 
part fH Orange County 

Duplex, 460.4 
460.2 

Blue 

1 

County: data lile (provides 
link to state data files 
through CLETSI 

Duplex, 460, D 

While 

1 

Local car-to car without 
repeater 

Simplex, 465.3 

Red 

1 

County: broadcast 

Duplex, 460.025 


t 

Digit’ll (to teleprinter! 

Simplex, 512,65 
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l-'or these f'unctitms, CAD is cKtlnialcd to icquite 5SD man 
lumis per year versus nearly 4000 man hours (wr year lor the 
oil] manual system. 

Del'ore stuilying the sample Incident shown in I'igurc |)-7, 
the reader should review the CRT I'orntat delinitions given in 
Figure U-6. Format (a) is available to the complaint board 
operator; lovmats (b) and (e) arc displayed to tlie dispatcher, 
liach has a keyboard to enter data into the system witli the 
aid of preset formats that are called up on the screen to mini- 
mize operator typing workload. 

The sample computer-aided dispatch described in Fig- 
ure B-7 simulates an armed robbery. The scenario focuses 
on the procedures used by the operations personnel in 
dispatching and controlling mobile units assigned to the 
incident. 


In the command center, the l■^lnlplainl niH'rator has one 
keylmaid and display for entering the citizen’s call lorseivice. 
llie dispatrhvr has a keyhoaid and two displays and operates 
a radio console. ()nc display shows the status ot ilie patrol 
lleet, the other has variahlf Jiimiats for incident summaries, 
and incident disposition and other special reports. 


In Figure U-7, column 1 describes the events in the robbery 
and column 2 the complaint writer’s activities, {!olunin ^ 
shows the changes in the incident display screen as the event 
takes place. Column 4 describes the dispatclier’s activities, and 
columns 5 and 6 show the dispatcher’s status and incident 
screens. 'Ihe manner in which itiformation is entered and 
retrieved from the display screens by the operations personnel 
is clearly demonstrated by this scenario. 


POLICC liUlLOING 


PUBUC 


COMPLAINT 

CONSOLt 


DISPATCU 

CONSOLE 


DISPATCH 

consoll 



14' 

CRT 


14" 

CRT 

14‘ 

CRT 


C/ 
/ D 




K-B 


K-B 


PHONE LINES 


WATCH 

COMMANDER 


19" 

19" 

CRT 

CRT 


COMMAND POST 

1 

r9" 

CRT 


MAIN 

COMPUTER 



void CHANNl I S 
MOD A I 

Ti ll F’RINtt R 


im rmi. di pt 

Fig. B-t. Huntington Btich Polica radio tyttem 
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kmi;r«i.ncv 

BUTTON 


OISPATCHEH CAt-t- CAR 
, VEHICue STOP 



EHEOUtNCY PRINTER 

SELECTION 

BUTTONS 


STATUS 

AVAItAUl.f 
f NIU)UT( 

AT SCI Nt 
iNVt St KiATlNO 
TO STATION 


! P\('l' f t >y. B '•> MODAT motiili' tliyitiil li'tium.il m>l,ill.iti<iM 

I'OUlf QlIAl.ir^ 



70 



u. I' liiry l)|s[<lny 

1 S .III' iiH-il li'i (ti-i, nil'll iiiliniiiiiii'in till- 
in liy ilu' ii|'fiii(nr .iml I'i'ium' I'.m "i tlu' 
IM'inuiu'iil I'liini'iiUT roiiiril, wliirti i' 'niln- 
nulii'ally uiiiimiihu'iI m .nnl ili'i'liiyi'il <'n Hu' 
tlisl>;ililK'i\ iiuiili'iil ('Kl. I (i-‘) niiil lli l.l 
nil- iliii’lii'.iii' rimi|>lninl I'liiiy li'rmiiU. I.inc^ 
MM imlti'iiti' iliy iiimiil.iint', in nitli'i 
u'vi'ivril, I'lili'ii'il Inin llu- 1 .> .ii'iii. Hn' inrnriiM- 
tiiin i' iIiii'IumU'iI m i!n' ilis'iililiyi''' imnli'nl 
CIM. 


I). Status Dinpliiy 

t'ar mimlicrs 'i'orrys|ioiulin(! u> lai lypysl ari.’ 
iliNl'Iayi'il niulor aiipioptialc liciulltins ot AVAII - 
Alll.r, I'NUtHHI:, A I SCI'.NI'.. IN VI'S II- 
tiAilNti. IU:ll!KNINU ro S1AI U)N. OUl. 
This in ft :r nut ion is ynlsTs’il ilits'i'lly Irom tits' 
U'liifls' via Ills' MnDAl niohils' ilal.i sysivni. 
WhsTs' applicahk'. tils' vast' miinbi'r to wliisTi ,i 
vi'his'ls' lias hs's'ii assiplls'sl is tltsplaVs'il lli'M to 
Ills' vsliisls'. ills' uppvr rltshl liaml solni't ills- 
plays Ills' hasklop ol ntussipns-sl tnsisls'nls ps't 
lis'at. Tills' 2 sliiuvs iitiil ,tA2 ri's)ns'sling a sar 
stop shs's'k, Tins' .1 iiiilis-ats's that 314 has not 
hs's'ii assiptis'il to a niolnis' unit m Ills' ssniipuk'i 
fill's, Tills' 4 iiiilisats's wliisti inolhls' units ars' 
transiiiittiiii; s'liisTps'iisy nis'ssaps's. 1 ins' S shows 
ollis'l cats tiansinitt inp nis'ssaps's. Tills' (' is Ills' 
aiiloliiiilis' in miinhiT wliisli appeal s svhs'ns'vs'r 
a inohils' unit ustts voici'-raslio. 


s'. DispalsTls'r lilsUli'iit Display 
A s'ompiits'r assipru'il itisisls'nl mnnln't aiipcats 
on Tills' 2 as svi'llas tillis' is'cs'ivi'il. ncats'sl stri's't 
tif applicahls'l, Apl. No., rs'portinp slismcl. Tils' 
lio\ No., ansi Heat No. Titis's .v.S iiulicals' Ills' 
naiiis' .iiitl plioiis' nnnihs't of the person leport- 
nip the ineislent, the iiniKsi .issipneil to the inci- 
(lent, ansi the type, eoile. pi units ssnle, .nisi 
ils'seiinlion of tlie iiistslenl. lines IIM2 null' 
e.ile assipns'sl Init timesolveil imiilenls. willi the 
ilisiilerit coils' on 1 ine '» I he hottoin (loilion ot 
Ills' ssieeii ilispl.iys .in .il'hresi.ils'ij seisinu ol 
the lop portion ol the siieeii ulussipm'i! itui 
sli'iits, lyiii coils', time tsceivesl. ailitress. iiiter- 
sei I slu's'l, u'potlinp illstllsl. 


ri«. B ti, (iHT iltsiilav ftiinnils 





EVENTS L.OQ 


O At fliOO «,m„ JuRMurv 10, 1976, two m«n «m«r 
a tiOMM At 3003 MAin St„ itirAAlan acRU))Ant 
with A hAfirttiHn, rnO tAkA colpr TV. 

t At 0: 1 1 A,m,, iiAlflhhnr paIU pallPA nnmolAint 
* wrIiAr And aavr mbhAty In nmoraii*. 


ACTIONS 


O lmiT)AdlAtaly puti paII an mleraphan* la 
^ diipAtchir, 8h» kayi addf All of InnldAoi into 
har dliptay, than tranimiti It to Bprrouflhi 2tiUU 
Gomputar for addraii varif Inatlon, Sht oontinuai 
to kay In Irtformam'i nama, addrait, phana 
numbir, and oiia daierlptlon: tranamiti caia to 
dlipiichar, Sha aiki Informant <o ramiln on 
llna. Informant provldai hir with daanrlpiian of 
5u»pni;lR ({joinan A). 


BURROUGHS 2500 TRANSACTIONS 

4 Verifies address, provides cross streets, 
reportlnp districts, and beat and gives arrest 
warrant, emergency medical, gun registrant, 
narcotic registrant, and sex registrant informa- 
tion at that location on complaint writer's 
screen. The response usually returns within 
6 SBC, so that the complaint writer can ask the 
Informant for additional data if the computer 
reports the address as Invalid, 


5 Case reappears, showing cross strueis, Other 
files negative, Complaint operator transmits to 
dispatcher (Screen B). 


8 Patrolmen in cars 2C3, 2683, 2A3 respond to 

call. 


A Patrolman sand digital "enrouta" messages to 
^ dispatcher. 




J’K I', 'CEDING PAGE 


pig. B'7. Armad robbery 
incident handled by 
computer-aided dlipitoh 

>X>LD0U3L£ 


K Not fxlmnli 




ACTIONS 


3 AI«rli ill can by volca to robbery in praflraM at 
2003 Main St, 


appears on dispatcher's incident screen 
* (Screen Cl. 


Assigns 2C3, 26S3, and 2A3 to this case. 
Priority 2 (Screen Dl, She transmits assignment 
to teleprinters in all cars (see below), The 
printers retype the case with suspects' descrip- 
tions, The incident screen shows that the 
assignments have oeen received and acknowl- 
edged (Screen El. She also acknowledges the 
"enroute" message, at which time the POP 
1 1/20 changes the status screen for these 
cars from "available" to "enroute," with the 
case number 030 by each car (Screen F), 


CAR TELE-PRINTER MESSAGE SENT 
BY DISPATCHER TO PATROLMAN 

lU ,'ii I.^ II? r, 

.’f'(-|’. '.:A|r, 

r\l T l-l- t,‘- M ■ \ \ tu ht 1 i 
IM s'.'ii M. hv:] 'r i 

^•A|^.: I H ^ , 

I'M r •• AK .-■( • .'I *, 

'• i i,C| .'.I \ 

I { I f AL“,'l !i ti-M » i l-:y t. ‘ -' 

\"V. Wy-.'. --Al I ■. iM.'.i KM ;■ 

'•Al'. 

Ml I' . * ' ! ‘ ' I • > fill 
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EVENTS UOQ 


Uniti 2C3, 26S3 arrl-.j nt Kane to Interview 
"^victim and Mitd "at Kane" digital memge. 


1 K Units 3 A 3, 20S3 stop suspects' car at InterHc* 
tion ol Beech Blvd, and San Olego Freewuv. 
2A3 sends digital massage "request vehiclu 
stop" to dispatcher and gives vehicle license 
number to dispatcher. 


Patrolman In 2A3 finds TV set in car. 


He arrests suspects and returns to 
station to book them. 


IQ Patrulman In 26S3 calls dispatcher for a tow 

trsirlc’ male Aft n RlnlAn PmnArfw Pftnnrl Ort 


qOMPi-AINI WHI 


I 


ACTIONS 


1 A At B : M e,m„ the Informant tells the pomplelnt 
* ^ writer that the robbers are leaving the hmtss 
and entering e car, She says she's going over to 
help her neighlKirs end hangs op. Car 3A3 
arrives at scene; sees two men leave scene In 
blue 1S73 Chevrolet sedan, with large boa in 
rear seel. Patrolman reports to dtspetcher that 
he 

e. Arrived at scene Idigiiel message) 
b, Sees susptnis and car leaving stiette heed' 
log ntirihwerd (voice message) 

He decides tn pursue vehicle and liv voles 
requests other oars to assist him, 


*1 1 Trensfars informant’s latest information to 
* * dispatcher by voice. 


truck; makes e Stolen Property Report on TV 
set, makes Vehicle Impound Report; waits for 
tow truck; then returns TV to owner. 


4 ATow truck arrives. Patrolman In 26S3 has 
•'^driver sign Vehicle Impound Report; gives him 
a ..upv, ?A3 sends e digital message "to station," 
when he arrives at station. 


41 2C3, 2633 complete victim Interview and return 
* ^ tn petrol. Each sends "available" status 
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EVENTS LOQ 


23 


3A3 Arr«it Rtpqrt In ntutlon houM to 
tmnMrlblne Motion, Thn trAntcrltiAr ontiri 
riport from hir ktyliiiArd In the fomtei ihown 
on the diipetohir Incident tcreen, 


25 


2A3 returns to street; tends digital “available'* 
message. 


toiii Qlffl EB AIfll I 



INCtDtNT DISPL 




ACTIONS 


^*^*^** IScrRHn K* and CQinplawd aRraanafor 
Pam* plaaranpa rr jgrt for enifv (mo polica 
(lata f ila In Burraugha S600 Rompuiar 
ISPrean Ul, 


O A All three cars assigned to 6asa 30, 2A3, 2C3, 
^ ^ and 26S3, again available for assignment as 


shown on status screen (Screen M) , 



< s 


KEY TO CASE CLEARANCE 
REPORT SCREEN 


u 

7400101 

Purmaneni file ciis« number 

c 

02100 

Claisification (firm-degree 
robbery) 

T 


Theft 

0 

3 22 

Daytime (Wed., 2200 hr) 

L 

00 

Location (code for single- 
family residunce) 

E 

01 

Entry (code for front door) 

W 

12 

Weapon (automatic) 

V 

27213130 

Vehicle (2, suspect 
vehicle; 72, year of vehicle; 
13, code for Chevrolet; 1 , 
code for sedan; 30, code 
for blue) 

p 

F300 

Property (F, code for TV; 
300, approximate value in 
S) 

R 

F300 

Property recovered 

M 


Modus operand! 

X 


Research field 

c 

2 

Clearance (2 indicates case 
cleared by arrest of adult) 




APPENDIX C 


A MULTIPLE JURISDICTION COOPERATIVE COMPUTER-AIDED DISPATCH SYSTEM 


ilircc iuijiiu'i'nl stihurhim ctmimuiulies in Illinois, in tlio 
vicinity of Chiciigo, ivccnlly instiilled u coopciiilivc (’Al) sys- 
tem for nse hy ;ill tlircc police depinlinents. The cities involved 
ure: 

• Oak I’ark, population fi2,5()(). 

• River l-'orest. population 14.400 

• I'orest I’aik. population 16.000. 

The system was designed and installed hy u firm in ('hatiipaign. 
Illinois (('omimmity Technology, inc.) and began daily opera- 
tion in April ld?4. It is known by the trade name of AIDS 
(Automated Interactive Uisputeh System). 

I'igure ('■! shows the configuration of the system in a 
simplified form. Note that it interfaces with the Illinois auto- 
mated law euforeement data base (l.liADS, Law Lnforcemeni 
Agencies Data System) and with the NC'IC, through the AIDS 
computer. 


I'igure ('•’ is a more detailed block iliagiaiii ot the Oak 
I’ark dispatch center, wheie the ('AD computer is located, 
showing also the interfaces with the River l•(>rest and i'oiest 
I’ark dispatch centers. Note that each of the rh'paiiiiiettts has 
two dispatch positions with display and keyboard, Only theOak 
Park department has a separate complaitit operator and a spec- 
ial dis|)lay )iosition for the chief, enabling, him to view any of 
the other active console displays. 


As I'igure C-2 indicates, the heart of the system is a Data 
(ieneral Nova minieomputer with 2-fK words of cote storage 
plus its loader, restart device, atid ch>ck. I he disk storage is a 
utiit with a capacity of million characters. Magnetic and 
paper tape drives are included in the system, along with a 
printer for general-purpose output from the computer. This 
is not the printer used by the dispatchers; the diagram shows 
that each department has a printer associated with the 
dispatching cotisoles. 







'Die consoles have single-screen displays. Each screen is 
divided into four areas. There are 24 lines altogether in the dis- 
play (with up to 80 characters on each line), allocated as 
folhiws: 


Line 1 • 1 1 

Incident record* or responses 
from LEADS or NCIC. 

Line 12 

Queries to LEAD.S or patrol unit 
status update or NCK'. 

Line 13 -21 

Unit status table or incident 
status table. 

Line 2.^ ■ 24 

Mes,sages from the CAD system 
or from rtiher operators. 


this system an inektent rccoid is calk'd a dispaich ticket. 


Eigure V-3 shows the alternate forms oi the display. Ihe 
operator can call up either type of information to the display 
area reserved for it, but with one screen he tannol have on view 
at Ihe same lime, for example, both the iiicideni status table 
and the patrol unit status table. 

The keyboard is iliusi rated in l iguie C ^, It consists of an 
ordinary typewmer keyboard plus special function keys shown 
to the left and right, Tite keys on the left arc editing keys for 
positioning the input and adding or deleting single characters 
or entries. The keys on iherifjit are dispatch function keys with 
tlie functions listed i.i Table I - 1 . 

The operation of the syslein is sunimari/ed in Table ( -.1, 
which lists all the entries on the incident recoid twith nitmhei 
ol characters alloted to eacli) and shows the source of the entry 
in each case. The imptrrlant p tint to be noted Is that the sys- 
tem Itself automatically provides many of the entries with no 
intervention rcrpiired by Ihe operator or dispatcher, .Serial 
numbers, dales, and all times are aulotualically entered bv Ihe 
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Nut’ii: 1 Tor coiwoniiMico, llu^su liolils jri; filloil liy the i,v'-,ti'm 
witli inli>i niiitK>n obliiinwl trum tlu! o|jetiiU)f eTtlJiessly 
Im tills piirimso, 

•) Mil! iiiJoiitiiition lor this fielil is delemiinetl Itom thu 
inculuiit uoile, d oiu; is siiiuilierl. Ullnifwise, it must be 
enti'fei.1 iiuiiuiiilly b,' tliii ii|ierjtoi . 

;i The Infoi million i.» tins lield is inbiiuid bom tin; 
lllCillioM. 

A When Anliimiitie Nomboi lilentibuition (AND or Auto 
Miiitie L.ociitioii lilenlil lOiil ion {AI.U eiiiiiitiilily bneonies 
iiViiiliibli: tlitoo!)li till! leluiilionn sysleiii, Ihesi! (iekIsiiKiy 
iilso be ciiibnii.itic.illy filliul. 


i'nin|iiili'i . On ib'Mi b. till* lv|ii’ iil III! iiii'iii Is rbli'ii'il by lib' 

I'lnniillb'l nil llie li.isl'i III llii' Mil I'li'lil i inli' i'llli'H '4 I'V ill!' 
ii|ii‘i:iliir, ll'i' I'lHli' h ili'b'MIlllieil by llle i iiib)>lili'i "li lib' 

III ilii> , III. Ill'S'. I'lVi'ii, iiMii III!' ili'ihMlini'iil (iiiylis .il'.iM'iib'b-il 

.iiiiiiiiiiilii iflly, Will'll till' ilisp.iii lii'i ,i'.M|'ii’. .1 I'.iniil mill tin' 
null imiiibei n, riib'ii'i! in tin' iiii'hb'iil n'i"nl itH'l nl ibn '..iiiii' 
iMiii' till' ntnl Miilih ii'i’iiiil IS ii|>il. lb'll. I lie liti’l ibe |)eiMi|i 
ti'i i'iviii)'. the e.ill (i I'liii'liiltH nih'i.ib'i m ili''n:i:i lii'i | n. eiileieil 
by tbe eniiiiinU’i liinn Ms |ii'iMiimel nn.iei. ;e. ;iie tin' iiiinieMit 
llie nllieeis (m nltici'il Ml the inilinl mill iissiitneil I he euiii- 
IMitei in.iliil.iiiis the link beiweeii ihe nii nleiii iiinl llie null 
iisMi'.iietl, iiiui niiikes llie ;i|i|iini)ii;iie eiiliies jinbiiiiiiiie.illy . 
iliiis, when Ihe nnil lepmls ninvnl ml the seeiie, ihe liine nl 
iitiiv.il is ;intiini;ilieiilly etiieieil in ihe iiieiileiit leeniil wlieii 
till' ihs|i;iteliei niuliites the miit sliilns tile, Ihe sitnie neenis 
when the iiK iileilt is elnseil. 

I he einisnle iipeititm iliiis nnikes vii linilK iin etiines tli- 
u'r'ily In the iih uleni leeoul miee llie tnlliiil Inisie nilmiM;itiiiii 
hits been eitleieil (whether liy ihe eumiiliiml ii)teiiilin m hy 
the ihsiKilehei tliieetlyb liy niuliiliti|i the stiitns Kthles. lie 
eiinses the teijiiiieti intbinnilloii bi be eiiletr'i! iiiitnmiilh ally in 
the iiieicleiif leetii il. 

(Jneties In leiiinle ibita bases (I I ADS ami N( l(') iiie 
enleietl tliieelly mi llie tlis)'alvliei‘s emisole, aiul the lespmisos 
laii he ilisplavetl theie as snmi as leeelved (.nilimb'.li they are 
iniiitetl mit mi ihe priiitei in any case). The computet auto- 
malically piepaies ipienes in the cmteci loiinat Im llie system 
lu'iiti; ipieiietl; lliis saves many misiiccesstn! atlenipls r■■snllln^ 
lioin Itivial rmimil etims in Iheiitieiy. 

Tli'O system keeps it liiiie-onleieii lile nt all eu'iils known 
to it, ami all iiiossaiU's ttansiti!l led oi teceived ovet the law 
ettrim eiiieni inlmmalion iielwoik ate also leemded. I his com- 
id'.'le lile Is used as the soniee Im miit activity U'l'oits and all 
statistical io|imts inclmliiij’, llie I'liilmin t'lline kepmis. 
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